Timeout in the RTO large batch subscription

Sometimes we met the timeout in the RTO large batch subscription. Any suggestion / experience on subscriptions of large batches?

e.g., subscribe 2000 ~ 3000 RICs in a batch, continuously for 100K RICs.

The aim is to subscribe all those RICs without timeout while do the whole subscription procedure as fast as possible.

Tagged:

Best Answer

  • umer.nalla
    umer.nalla LSEG
    Answer ✓

    Hi @Frederic

    The usual recommendations are to pace the request i.e. limit how many requests you make per second / minute etc Either the RTO server you are connected to cannot cope with the pace of your request or your application cannot process the response quickly enough and the RTO server is disconnecting your application as the buffer it maintains for your connection overflows.

    Also, if you are doing some processing in the OnRefreshMsg/onUpdateMsg callbacks, try and spin that off into a separate thread - these callbacks are executed in the main API thread context and if you spend too much time in the callback, the API cannot read the data from the RTO server in a timely manner. If you search this forum for 'slow consumer' you may find other useful information.

    You can also try horizontal scaling i.e. create more than one OmmConsumer instance - where each instance subscribes to a subset of the overall watchlist.


Answers