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.

@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?

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.