@Paolo Parlapiano

I think your interactive provider application needs to handle the onReissue callback.

    void onReissue(const refinitiv::ema::access::ReqMsg& reqMsg, const const refinitiv::ema::access::OmmProviderEvent& event);

When ADH sends a request message with the same streamID, the interactive provider application will get it through the onReissue callback.

This behavior is controlled by the cacheLocation configuration in ADH.

Hello @Paolo Parlapiano ,

I think this is something else, and likely is not infra.

To test, if you just run your 2 consumers, directly to your IProvider, bypassing any infra, do you see the same effect?

I run a quick test: I run EMA Java IProvider 280_MP_Perf, from RTSDK 2.0, as is, and point two of EMA Java Consumer 100 at it. They both on streamId 5, and they both run without issues.

However, if I replace IProvider 280 with the simplest IProvider 100, it will fail on the second request. It is coded to specifically only accept one request, and so it will fail on the second. Several other example IProvider do the same.

Therefore, I suspect you are re-using some of the single request IProvider code, i.e.

if( itemHandle != 0 )

in case if my guess is off, testing your custom IProvider and example consumer(s) separately from infra still could be helpful to finding out more information about the issue.

Hi @zoya farberov,

thanks for your comment.

I've also tried the same test before creating this question. My IProvider works without issues with two consumers of the same RIC connected directly to it. I've also seen the same behavior of yours: they both use the same streamId=5, and that is not causing any issues: they both receive data and updates as expected.
However in this scenario there's a difference: the two consumers correspond to two different connections to the IProvider, probably this aspect makes the difference in the EMA logic?

My application code traces in some applicative logs any requestMsg as soon as it is notified (regardless of the internal status), but in the scenario of the issue I don't have any trace at all about that.

Note: in the prod environment, the user is not sure about how to configure the cacheType and cacheLocation parameters of the ADH, so maybe they just need to tune those settings in the correct way?
To be more precise, what happens if the ADH has no cache configured, and multiple consumers make requests to the same Interactive provider for the same RIC? My understanding is that each request is forwarded to the Interactive Provider, which means (If I am correct) that all the requests reaching the provider will be sent on the same connection, same streamId, and same RIC name. Is the provider expected to handle this case?

Thanks

Paolo

Hello @Paolo Parlapiano,

Thanks for confirming that you are able to run the second consumer connection successfully, when run direct- that eliminates some of the possible causes.

I believe the requests from two different consumer apps via ADH should be received by IProvider app the same, as via direct connection.

I hear you, that the second request is not being received on your side, by the custom IProvider app.

Next step on my side, is to try to verify the same on my side (test with an example IProvider against testbed RTDS) , and unfortunately, my testbed is unavailable at the moment, we have had a hardware failure that was just discovered - I will get back on this, as soon as am able to test.

Thanks for your patience

Would suggest the same test with RTDS on your side, example IProvider (that works direct) and example simple consumers connecting, rather then custom, as a way to find out more and hopefully understand the issue.

---

As a developer, can not give expert advice on how to configure ADH caching, I would suggest contacting your local experts, market data admin/group, and/or configuring caching the same, as on your prod infrastructure for prod services, such as ELEKTRON.

If that would help, we have:

*ELEKTRON_DD*cacheLocation : srcApp
*ELEKTRON_DD*cacheType : sinkDriven

.configured