Rates stop updating after a while and need to restart the whole application to resume streaming
The rates will stop update after a while need to restart the whole application to resume streaming.
And it affects all the pairs, not just any particular one. I think it is related to unsolicited RefreshMsg, but currently we don’t know how to initiate a new data flow upon this event without restarting the application.
"Refresh Message: The Interactive Provider can use this class to respond to a consumer’s request for information (solicited) or provide a data resynchronization point (unsolicited). The non-interactive provider can use this class to initiate a data flow on a new item stream. Conveys state information, QoS, stream permissioning information, and group information in addition to payload."
sample RICs:
AUD=, AUDON=, AUD1W=, EUR=, EURON=, EUR1W= etc.
Hi @Dennis Au
Can you please advise how you respond to / process the Unsolicited Refresh msg?
You should not need to re-subscribe to instruments after an Unsolicited Refresh. As explained in the documentation, it is used for data resync - sometimes after a stale/suspect scenario.
Are you logging all your StatusMsgs? Do you see any suspect status msg prior to the Unsolicited refresh?
Also, are you consuming data from Refintitiv Real-Time Optimised (cloud-based) or an internal ADS (RTDS) system? IF using an internal ADS, please speak to your Market Data team - they can check their logs around the time of the Unsolicited refresh to help understand what may be occurring.
If you are connecting to RTO, then I recommend you raise a ticket with the RTO Team - who can also investigate the cause of the Unsolicited refresh and lack of updates thereafter.
At first, we observed the rate update always stopped after Unsolicited Refresh msg, then I tried a few approaches to resume the stream:
- Resubs when the Unsolicited event happened
- Resubs all the pairs every 1 hour
- Close and re-initialize the connection every 1 hour
But all of these doesn’t help, the rate stream still stopped unless we restart the whole application. I did log all StatusMsg, and the Unsolicited message is the only anomaly thing (pattern) I found.
You may need to enable tracing in the API. With tracing, we can see the incoming and outgoing messages.
Did you see a disconnection?
Typically, ETA will not recover a connection or subscribed items unless you are using the ETA Value Reactor with Watchlist enabled.