Why Connection to electron service keeps dropping every 15-20mins

13»

Answers

  • Thanks for your response. So, what example should I look at for streaming? the way we are using EMA is by specifying Thread.sleep(<seconds>) which is not exactly streaming and its unstable at small refresh rates.

  • I looked at Consumer450 example given in the link you provided but thats using Thread.sleep(90000) so its not streaming

  • Hello @vuk.magdelinic,

    Example Consumer450 , Query Service Discovery, shows streaming from RRTO service.

    Thread.sleep(90000) defines how long example's main thread runs, before it exist. This works best for the purposes of example.

    If you would like the example to run indefinitely, please feels free to replace this sleep with:

    while(true)
             Thread.sleep(1000);

    However, does the example run properly for you, displaying streaming prices, till it exists.

    I hope this helps?

    ---

    Just in case, if you will have a question that is not part of "Why Connection to electron service keeps dropping every 15-20mins", I encourage you to ask it as a new question, and to include a link to this question, in case it is relevant to the understanding the new question.

  • @zoya.farberov from what I understand, if I'm using Thread.sleep(<time>) in my code that means its not streaming, I'm still pulling the data every <time> secs.

    I'm asking if there is a way to get each and every quote, i.e. you mentioned 3 quotes per sec.


    Reason for continuing in this thread is because the goal of this question was to have an uninterrupted stream of data from Elektron at max 1 sec refresh. And we have not been able to achieve it.


    We have tried snapshots as well as deltas, but each time we do Thread.sleep(1000) or value less than 1000, the stream fails within an hour or 2 hours with the below exception (as stated earlier):

    Exception in thread "main" java.lang.NullPointerException
        at com.refinitiv.ema.access.SingleItem.rsslSubmit(ItemCallbackClient.java:2994)
        at com.refinitiv.ema.access.SingleItem.open(ItemCallbackClient.java:2856)
        at com.refinitiv.ema.access.BatchItem.open(ItemCallbackClient.java:3823)
        at com.refinitiv.ema.access.ItemCallbackClient.registerClient(ItemCallbackClient.java:2156)
        at com.refinitiv.ema.access.OmmBaseImpl.registerClient(OmmBaseImpl.java:457)
        at com.refinitiv.ema.access.OmmConsumerImpl.registerClient(OmmConsumerImpl.java:143)
        at EMAConsumer.Consumer.main(Consumer.java:673)

    So, as much as we appreciate your help and support on this ticket throughout, we are not able to achieve a refresh rate of 1sec or lower yet. Stream runs uninterrupted for 2sec refresh rate for both snapshots and deltas (i.e. with interestAfterRefresh(false) and interestAfterRefresh(true))

  • Hello @vuk.magdelinic,

    Glad to explain that this specific statement, thread.sleep is not facilitating pulling data. It is preventing the main thread of the example from exiting, while dispatching is handled via API asynchronously. However, as soon as the main thread exists, the python app will exit. Hope this explanation helps?

    Please confirm that you are able to run the example as is, and get the continuous stream of data, every update that is published by the service.

    Refinitiv Realtime Optimized service (RRTO) is conflated, to cup the quote updates at 3 per sec, while publishing every trade (is is trade-safe).

    Therefore, if you consume, for example, IBM.N, you should see from 0 to 3 quote updates per sec, you will only get the updates as they are made available by the service, i.e. if <=3 were published by the venue, you will see every update, if >3, you will only see 3. At off-market you should see no updates. Does this explanation help?

    The example 450, unmodified, will receive every update that is published by the service. This functionality is available as is, with no design or coding required.

    If your business tier requirements are to receive the updates at 1/sec, you would need to either implement this in your custom consumer code, keeping track of the updates received and do not process/pass to the business tier the updates that you don't require; or discuss with your Refinitiv account manager retaining Professional Services to design and implement this and any additional requirements on behalf of your organization.


  • @zoya.farberov I have confirmed multiple times now that when we try out any example, we are getting the above NullPointer exception. Are you able to comment on that because it's refinitiv code that's throwing that exception??


    We want a service that has 100% uptime. So, please try it at your end and let it run atleast for 12-15hrs uninterrupted and tell us if you are getting the same exception.


  • Hello @vuk.magdelinic,

    Let me start by confirming, are you running the example EMA Java Service Discovery 450, that came with RTSDK 2.0 "as is" only modification is

    // Thread.sleep(900000);           
       while(true)
            Thread.sleep(1000);

    when you run into NullPointer exception?

    I am double-checking with you, as previously:

    You have focused first on Value Added objects, reported lost connection after 15-20 min. I have rebuild Value-Added objects for use with RTSDK and provided you with the version. I have run this version for several hours without losing connection or seeing exception.

    You have discussed you were getting NullPointer exception, when you run snapshots every second. We have discussed that snapshots every second are not the intended usage of the API.

    The NullPointer that you have included before, was on registerClient! I.e. it could not have happened if you run 450 as is, for 12-15 hrs, as it only calls registerClient once, at the very beginning.

    So if you are able to confirm this is what you run, then, I am glad to run the same for 12-15 hrs, if that would be helpful?

    Otherwise, please proceed as suggested, and let us know how this works for you?

    Thanks