disconnected due to an overflow condition

Bhimrao.Ghule

Hi,

We are using ETA C++ library to connect and fetch data from TREP. sometimes, we saw an error message in TREP/ADS "disconnected due to an overflow condition" . And we observed that our connection is terminated by TREP and data Market data update has been stopped completely until restart of a component. Please help me to understand that, which event we will get from TREP server in case of such error. I believe that, we will get RsslReactorChannelEvent in callback, but not sure which eventType

Jirapongse

@Bhimrao.Ghule

Typically, the "disconnected due to an overflow condition" message indicates that the connected application is a slow consumer. The application is unable to handle the update traffic in a timely manner.

For example, if the application can handle only 100 update messages per second and the total update rate of all subscribed items is 1000 update messages per second, this indicates that the client is a slow consumer.

When the client is a slow consumer, ADS is unable to send messages to the TCP buffer so it puts messages into the internal output buffer. The messages in the internal output buffer will be sent to the TCP buffer when the TCP buffer is available.

If the internal output buffer is full, ADS will cut the connection and report this message ("disconnected due to an overflow condition").

The number of output buffers in ADS can be increased via the guaranteedOutputBuffers and maxOutputBuffers configurations.

*ads*"${port}"*guaranteedOutputBuffers : 200
#help


  guaranteedOutputBuffers: { 1 - N buffers }


  The number of output buffers guaranteed per channel.
  The meaning of guaranteed is that the output buffers are pre-allocated
  to the channel. (See also description of poolSize parameter).


  Default Value:  200
#end


*ads*"${port}"*maxOutputBuffers : 400
#help


  maxOutputBuffers: { 1 - N buffers }


  The maximum number of output buffers to allocate per channel.
  The (maxOuputBuffers - guaranteedOutputBuffers) defines the number of
  buffers to be dynamically created to be requested as needed from the pool
  per channel. Mounts will initially be allocated the guaranteedOutputBuffers
  and can take more from the buffer pool as needed until they reach the maxOutputBuffers
  limit.

These configurations may reduce the number of disconnections due to an overflow condition. However, the better approach is modifying the application to run and process messages faster.

Moreover, in some scenarios, the problem could be from a network issue. You may need to contact the network team to check the network bandwidth.