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
Best Answer
-
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.
0
Answers
-
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.
0 -
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
0 -
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
0 -
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
0 -
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.
0 -
Thanks for confirming.0
Categories
- All Categories
- 6 AHS
- 37 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛