Refinitiv RTO price feed health checking

Hi Refinitiv!
We are using Java EMA/ETA library for connecting to the Refinitiv RTO, and want to have a reliable health checking mechanism.
Currently, we made a decision to restart a client on 2 factors:
- if the stream state field in StatusMsg and RefreshMsg is not OPEN .
- if we did not receive any price updates with the RefreshMsg or UpdateMsg for more than 2 minutes.

But with this approach (second part), we have an issue with client restarting every weekend multiple times due to no updates coming on the weekends.

Can you suggest what would be the best practice to perform health checks?

Find more posts tagged with

eta-api

ema-api

refinitiv-realtime-optimised

#technology

#product

Accepted answers

Jirapongse

@denys_vakhovych

Thank you for reaching out to us.

Typically, there are three scenarios that cause the application stops receiving real-time data.

The server cuts the connection. In this case, the item streams will be Open/Suspect. Then, the API will reconnect to the server and re-subscribe to all items.
The server closes the login stream. In this case, the application needs to create a new OMMConsumer instance or the application needs to be restarted.
The service is down. The item streams will be Open/Suspect and then will be changed to Open/Okay when the service is up

EMA applications can get the disconnection and login closed events by registering to receive login events (ex330_Login_Streaming). EMA applications can get service events by registering to receive directory events (ex331_Directory_Streaming).

All comments

Jirapongse

@denys_vakhovych

Thank you for reaching out to us.

Typically, there are three scenarios that cause the application stops receiving real-time data.

The server cuts the connection. In this case, the item streams will be Open/Suspect. Then, the API will reconnect to the server and re-subscribe to all items.
The server closes the login stream. In this case, the application needs to create a new OMMConsumer instance or the application needs to be restarted.
The service is down. The item streams will be Open/Suspect and then will be changed to Open/Okay when the service is up

denys_vakhovych

Thanks a lot, @Jirapongse!

Taking a look at the examples, what about using ChannelInformation from ex170_MP_ChannelInfo, in addition to what you described, and calling consumer.channelInformation(ci) repeatedly to catch an event when, for example, a ping was timed out?

Otherwise, how could we know that a connection was, for example, interrupted? I believe we would not receive any events in this case? We want to prepare ourselves for all kind of scenarios, including very rare ones.

EXPLORE OUR SITES