Multiple requestMsg for same streamId and RIC

Hi,

please help me with the following issue.

Scenario: EMA Interactive provider -> ADH -> ADS -> 2 consumers

Consumer 1 starts and subscribes to a RIC.

After some time, Consumer 2 starts and subscribes to the same RIC.

On the EmaTrace of the provider side, I see 2 requestMsg coming from the ADH/ADS for the two consumers. The two requests have the same streamId.

As result of this:

the first requestMsg is notified by EMA to my application, and served properly on the first consumer (data is received correctly)
the second requestMsg is not notified at all to my application (I guess because it's about the same streamId and item id?)
after 5 minutes, the ADH/ADS closes the item request for timeout; as result a closeMsg is sent to my provider; after this, also the first consumer stops receiving data

Question: why is the infra sending to the provider a two requests despite there's already a stream opened by the ADH/ADS for that item?

Is that case to be handled on provider side? Or is this a sort of configuration issue on the ADH/ADS?

Thanks

Best Regards,

Paolo

Find more posts tagged with

ADS

ADH

request

ema-api

interactive-provider

Accepted answers

Jirapongse

@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.

All comments

zoya faberov

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.

Paolo Parlapiano

Hi @zoya faberov,

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

zoya faberov

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

Jirapongse

@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.

Paolo Parlapiano

Hi @Jirapongse ,

thanks for the reply. In fact, my IProvider does not implement the onReissue callback.

Since in this scenario the user can also customize the configuration of the ADH, what is (if any) the suggested tuning of the ADH settings to avoid this kind of issue? Would the following combination of settings work?

caheType = sinkDriven
cacheLocation = ssl

Thanks

Paolo

Jirapongse

@Paolo Parlapiano

Yes, the SSL cacheLocation and sinkDriven cacheType should work.

With these configurations, ADH will get images from its cache instead of forwarding item requests to a source application to get new images.

EXPLORE OUR SITES