EmaConfig: MaxDispatchCountApiThread/MaxDispatchCountUserThread options don't work properly

eleneldil

I think I've found a bug that breaks these options processing.
(First, of course, I'd tryied to use MaxDispatchCountUserThread and it appeared that my IProvider sometimes received messages beyond the MaxDispatchCountUserThread value during one dispatch() call. Then I'd debugged how could it happen...)

The problem is in the way how the dispatchAll() method of com.refinitiv.eta.valueadd.reactor.Reactor counts the messages received.
(All line numbers are for EMA/ETA version 3.6.3.1 which are parts of RTSDK-2.0.3.L2)

Lines 5137-5139:

int bytesReadBefore = dispatchOptions.readArgs().uncompressedBytesRead();
if ((retval = performChannelRead(reactorChnl, dispatchOptions.readArgs(),
      errorInfo)) < ReactorReturnCodes.SUCCESS)

later, form line 5153:

// only increment msgCount if bytes are actually read
if ((dispatchOptions.readArgs().uncompressedBytesRead() - bytesReadBefore) > 0)
{
       msgCount++;
}

Everithing looks reasoned. But diving deeper into the com.refinitiv.eta.transport.RsslSocketChannel class (the same is true for other com.refinitiv.eta.transport.Channel implementations too), in the `public TransportBuffer read(ReadArgs readArgs, Error error)` method, in the line 1283 I see:

((ReadArgsImpl)readArgs)._uncompressedBytesRead = 0;

So, it zeroes _uncompressedBytesRead, but dispatchAll() expects it to be increased upon its old value.

So if the next message in a row is not longer it wouldn't increase msgCount, i.e. wouldn't be counted against the limit.

umer.nalla

Hi @eleneldil

Thanks for your investigation and report.

I have reported your above post to the RT-SDK dev team directly on GitHub:

EmaConfig: MaxDispatchCountApiThread/MaxDispatchCountUserThread options don't work properly ? · Issue #187 · Refinitiv/Real-Time-SDK (github.com)

Hopefully, they will investigate and respond soon.

Feel free to watch the above issue on Github - I will also try and post any relevant responses here.