My application can directly process the data from the Elektron Edge server in the reactor's thread or put it on a queue a process it in a worker thread.
Doing the former certainly takes less time since there is no need to copy the message and place it on a queue and doing the latter keeps the buffer in the Elektron Edge server at minimal levels since the reactor thread is not doing any substantial processing.
Queuing the data adds a bit of latency so I'd like to be able to heuristically set a flag to queue or not based on whether a backlog is accumulating in the Elektron Edge server. I could certainly use a RECONNECT event as such an indicator, but by that time, it's too late and I've most likely lost data during peak processing time.
Being able to query the buffer depth (or if it's already being sent in a field of one of the messages) or to set a flag indicating that the application would like to receive a status update regarding the (backlog) buffer size once a certain threshold (# of msgs or %) is reached would allow the application to tune it's behavior automatically.
There is no available method for consumer client to query the output buffer depth of Elektron Edge server.
ADS has features to handle the output buffer overflow condition. User can set high and low-water limit in percentage of maximum output buffer in ADS configuration. Following messages will be logged, once output buffer depth of a channel reach high-water limit or decrease to low-water limit. If you have an access to the Elektron Edge log, you may use the log to monitor the overflow condition.
<ads: Warning: Tue Dec 06 01:36:32 2016> Output threshold breached for username at position 192.168.1.1/net on host TPL-A using application 256 on channel 258. <END> <ads: Warning: Tue Dec 06 01:37:00 2016> Output threshold OK for username at position 192.168.1.1/net on host TPL-A using application 256 on channel 258. Resuming normal operation. <END
Using the TSRC console, I can see this information, but that does not allow the program to dynamically adapt to the conditions it is creating on a session at the server.
Without this information, I've no choice but to enable copying all messages to a queue to be processed by a worker thread allow the reactor thread to receive messages as rapidly as possible,
Unfortunately this approach, while maintaining connectivity does so at the expense of additional latency (and to a lesser extent memory).
I has hoped to be able to dynamically adapt based on information from the server.