Hi @davinb,

As a quick sanity check, for 100k instruments initial subscription list requirement:

• You have increased GuaranteedOutputBuffers params from default to a sufficient, to sustain heavy outgoing load
• You are using batches of requests commensurate with your requirements, to issue multiple requests efficiently?
• You are spacing batches of requests, there is a minimal time interval built in, between batches?
• You have no heavy processing or calling slow external devices in the main callback, you are not tying the main thread, any significant task triggered by main callback is handed over and handled by worker threads?

Hi @davinb,

Does the instrument ever recover at all. What happens when you subscribe to the same instrument from another consumer - does that get updates. It could be that particular item stopped trading or was delisted. Do you see any messages in ADS logs. Does ADS still show same number of open items?

Thanks for the reply. No it is not delisted. An example was JYU0 . I had another instance of my program running on another server and it continued to tick. If I called OmmConsumer::unsubscribe(handle) then resubscribe, it started working again. I don't see any messages but I will check with my tech support about ADS logs.

My max output buffers is 6000, guaranteed output buffers 6000, number input buffers 30. What would you recommend for these settings?

I'm not using batch requests, I will try that and/or putting in a delay between requests.