handle unregister problem

wangfugen2015

Hi, my application subscribes rics from starting option chain record like 0#OPRA-A at 9:10 EST time every trading day. On each callback to onRefreshMsg, I saved handle value of OmmConsumerEvent::getHandle() into a set structure and start process this refreshmsg.

Then I continously received callback to onUpdateMsg and process it. At about 20:25, my application will call OmmConsumer::unregister() with all value from previous mentioned set structure iterately to release subscription for option rics.

On Feb 16th 13:48, my application suddently received many timeout message, which I formated with log message like:

02/17/21  02:49:40:431 [server/emaopt/consumer.cpp:371] [19:140175670441728] - status msg with symbol:TDGO192130000.U, state:Open / Suspect / Timeout / 'Request timed out.'
02/17/21  02:49:40:431 [server/emaopt/consumer.cpp:371] [19:140175670441728] - status msg with symbol:TDGO192130000.U, state:Open / Suspect / Timeout / 'Request timed out.'
02/17/21  02:49:40:432 [server/emaopt/consumer.cpp:371] [19:140175670441728] - status msg with symbol:TDGO192130000.U, state:Open / Suspect / Timeout / 'Request timed out.'
02/17/21  02:49:40:432 [server/emaopt/consumer.cpp:371] [19:140175670441728] - status msg with symbol:TDGC192131000.U, state:Open / Suspect / Timeout / 'Request timed out.'
02/17/21  02:49:40:432 [server/emaopt/consumer.cpp:371] [19:140175670441728] - status msg with symbol:TDGC192131000.U, state:Open / Suspect / Timeout / 'Request timed out.'

I found lost quote update msg for many rics, but there's still some update msg for some rics. The timeout continues and never restored to normal automatically. We contacted helpdesk and developer from your company, they found the ads main thread consumes 99% cpu. Seen from ADS Monitor screen, the open items has not decreased until I shutdown all my applications. (for detail, you may refer case 09632031).

My problem is why the unregister function not actually work at 20:25, as the open items never decrease and there were still lots of timeout log from my application.

Suppose I registered ric A and received RefreshMsg of A, I saved handle from RefreshMsg. Then if timeout occurs for A, I shall receive StatusMsg indicating 'Request timed out'. Will the handle in onStatusMsg same as onRefreshMsg for ric A? Here, I may suggest two case, one is my application still connected to TREP1, second is my application found network problem to TREP1 and try re-connect to TREP2. What will the value of handle be for both case ?

Also, I want to known when the first connection to TREP server will be established when my application starts runs? Is it when I create OmmConsumer object ? I found when in non-trading time, it seems my application keeps tcp connection to TREP server. Is there any method that I can close that connection if in non-trading time ?

Find more posts tagged with

elektron

elektron-sdk

refinitiv-realtime

rrt

elektron-message-api

ema-api

time-out

Accepted answers

umer.nalla

Hi @wangfugen2015

As long as the StatusMsg does not indicate a StreamState of closed, the stream remains open and the associated handle will remain the same. If you receive StreamState of closed, then the handle will no longer be valid either - as the associated stream has been closed off by the API or the ADS.

In terms of your connection related question, creating the OMMConsumer results in two relevant actions (amongst others)

It established a network connection with the server
It sends a login request to the server for you behind the scene

If the login request is accepted then you can consider that you are 'connected' to the server

If you wish to 'disconnect' from the server and close all your open data items streams, you can close the Login stream (i.e. call unregister for Login handle). This will log you off from the ADS server and automatically close all open item streams (and therefore all handles associated with the items will no longer be valid either).

A number of the supplied Consumer examples demonstrate how to get the Login Stream handle - including example 333

If you note in example 333, it calls registerClient explicitly for the MMT_LOGIN request - and you can therefore store the returned handle and use that later to close the Login stream (and thereby all open items).

Example 330 does things slightly differently, it does not explicitly call registerClient for MMT_LOGIN. However, when you run it - you will note that the first RefreshMsg you receive is for the Login response and you could extract the handle for the Login stream at that point - if you prefer.

All comments

umer.nalla

Hi @wangfugen2015

In terms of your connection related question, creating the OMMConsumer results in two relevant actions (amongst others)

It established a network connection with the server
It sends a login request to the server for you behind the scene

If the login request is accepted then you can consider that you are 'connected' to the server

A number of the supplied Consumer examples demonstrate how to get the Login Stream handle - including example 333

wangfugen2015

@umer.nalla Thanks for your reply. About the second question, I referred to examples you mentioned and now I know how to deal with the connection to ADS servers.

For the first problem, I still have some puzzle. We have two ads servers, each with configurations in server's distribution.conf

*ads*DBU*itemLimit : 850000
*ads*DBU*itemLimitPerMount : 2000000000
*ads*itemLimit : 850000
*ads*itemLimitPerMount : 2000000000

That's to say, one single ads server can accept at most 850k rics at most. At the time when timeout occurs, your developers found on ads monitor screen that there were about 200k options rics in pending state. Currently us options totally has about 1.2M rics, in our production deployment, we rough split each 600k rics to each server. But due to one test at Jan 30th, your developer restarted trep1, and thus make connections original directed to trep1 automatically switched to trep2 by ema sdk, which made it overpass the ads limit of single ads server. By afternoon of the next day, your developer examined that the main ads thread continues with high cpu usage at 99%, and my application continues output timeout message. Generally my application will unregister all handler from refresh message when market close. So it seems that the high cpu usage cause my unregistration not work, as we still found large number of open items. Can the huge number of pending options cause the high cpu usage?

umer.nalla

Hi @wangfugen2015

I am not an ADS / RTDS (TREP) expert so cannot say the high CPU usage on the ADS.

Certainly, it would seem like a reasonable assumption that high CPU usage on the ADS meant that it did not process your unregister calls i.e. item stream Close requests.

If that is the case, it could make more sense to unregister the Login handle rather than unregister 600k individual instruments - to reduce the number of incoming close requests the ADS has to deal with. However, as mentioned I am not an ADS expert and not familiar with its inner workings. I recommend you continue to work with the ADS support team to identify the root cause and potential mitigation options. The ADS support team may be able to advise on whether the single Login stream close request is more efficient from the ADS internals perspective.

EXPLORE OUR SITES