C++ EMA API Request Time Out

We use Refinitiv EMA API to send request and receive stream data (interestAfterRefresh = true).

We had run the same program with in 2 different servers. No error returns from one of the server, but in another server, most of the RIC Codes requested is time out.

Here is a screenshot for a portion of the RIC Codes:

We had tried extending the RequestTimeOut value in EmaConfig.xml to 10 minutes (600000ms), but the same error happened. In the EmaTrace file, we can see the outgoing message for the RIC Code, but we cannot find the incoming one.

We are aware that sending 1700+ request in a loop might cause throttles. Is a pause between requests recommendable ? If so, how long the pause should be ?

Find more posts tagged with

refinitiv-realtime

ema-api

time-out

Accepted answers

Gurpreet

Hi @Kia Wai,

If your application always works in one deployment, and not in another one, I would conclude it is a network/resource(CPU) issue. Is it possible to deploy this application instance in another server is identical configuration as the first one?

Barring this, I would recommend that you open a service ticket at my.refinitiv.com, to have the product team look at the system logs and find out the reason for the timeout. It could very likely be due to resource constrains within your environment.

All comments

Gurpreet

Hi @Kia Wai,

Please provide more details about the application - is it a new app; where is it sourcing the data from - inhouse RTDS or RTO?

1700 instruments is quite manageable instrument count for an EMA C++ application. There seems to be a network issue either in your server or in the market data servers. Also, 10 minutes seems a very long timeout period. In my recent application, I was able to price 3K instruments in 2 seconds using a high throughput market data setup.

The first test you can do is using the testclient, to measure the performance. See this article about the use of testclient. Even though it is about using websocket API, same procedure would be applicable when using RWF.

Also, if you are using the local RTDS, please look into ADS logs for any clues pointing to the bottlenecks. A common issue is hogging the event callback thread - it should be release as fast as possible.

wasin.w

Hello @Kia Wai

While my colleague already gave you clear steps to verify further, please note that you can run the testclient tool with the following command for the RSSL connection:

testclient -S <RTDS Service Name> -h <RTDS Address/Hostname> -ct rssl -p <RTDS RSSL port> -l stdout -X -f item.txt -v -d 3 –Z –md <domain> –u <user>

Kia Wai

Hi @Gurpreet, @wasin.w,

1) Yes it is a new app, and it is sourcing the data from RTO.

2) For the RIC Code that doesn't encounter timeout, we did receive response / incoming message at around 4 seconds after we sent out the request.

3) Can you elaborate "high throughput market data setup" ?

wasin.w

Hello @Kia Wai

Could you please give us more information about the issue?

The RTO endpoint name that works fine
The RTO endpoint name that always encounters the problem
Are those servers in the same region (ap-southeast, eu-west, us-east?)
Does the problem always occur with the same set of RICs or exchanges?
The version of the EMA API that you are using

Kia Wai

Hi @wasin.w,

- The RTO endpoint we used is:

which we believe is handpicked by API itself.

- The same RTO endpoint is used by the app.

- Both servers are in the same region (ap-southeast).

- The problem seems to occur at random RICs.

- EMA API version we used is RTSDK 2.0.0

Gurpreet

Hi @Kia Wai,

Kia Wai

We had done some further testing regarding this issue, turns out the way we processed the data after receiving it might causes the traffics.

For now, we had change our way of processing data by saving the data into a file and process the data from there, instead of processing it straight away after receiving it. The time out issue does not occur anymore with this method.

Thank you for your assistance. @Gurpreet , @wasin.w

EXPLORE OUR SITES