How to get a list of items per request.

anton.filimonov.ext
anton.filimonov.ext
in EMA

Hello.

We are trying to transfer our code from RFA to EME (as adviced here: https://community.developers.refinitiv.com/questions/80627/after-switching-deployed-application-with-rfa-to-n.html?childToView=80967#answer-80967). But from totorial looks like we can get data only for a one item per request. So my question is this a usual situation or is it possible to get data for the list of items per request? And how we can inform our application what all data already requested and ready for use instead of waiting one or more minuts (Thread.sleep(60000);).

Could you please give me a piece of code or link to the suitable example.

Thank you in advance.

Tagged:

Best Answer

Answers

  • anton.filimonov.ext
    anton.filimonov.ext

    Hello wasin.waeosri. Thank you for your response and your help. More or less your understand my question right. So, I will try to look on your links before. I hope they helps me fix my issue.


  • umer.nalla
    umer.nalla

    Hi @anton.filimonov.ext

    Note that for the examples you are looking at the Thread.sleep(60000) is just there to allow the example to run for a while before exiting. The data/event callbacks are on the API thread context and invoked asynchronously - please follow the advice above as provided by my colleague.


  • Unknown
    Unknown

    thanks

    for more information

    Impression of Planet Proxima Centauri with New the stars, Centauri a and Centauri B - Information about Proxima Centauri .


  • anton.filimonov.ext
    anton.filimonov.ext

    umer.nallawasin.waeosri

    New question from my side.

    In RFA was possible set the quality of request. For example Best/Worst rate and Best/Worst Timeliness. Is this attributes so critical and how we can set them in EMA api?


    Tahnk you in advance.

  • umer.nalla
    umer.nalla

    Hi @anton.filimonov.ext

    Can you confirm if you have multiple source/services available on your infrastructure that provide different QOS in terms of rate and Timeliness - otherwise these QOS settings will have no impact?

    With regards, how to set the QOS please see the Ema example 101_MP_QosPriority included with the RTSDK which shows how to set the best rates.

    e.g. for EMA Java

    consumer.registerClient(reqMsg.serviceName("DIRECT_FEED").name("IBM.N").qos(Timeliness.REALTIME, Rate.TICK_BY_TICK).priority(2,1), appClient);


  • anton.filimonov.ext
    anton.filimonov.ext

    umer.nalla.

    Thank you for your replay.

    Yes, I have already seen this example. But looks like it is possible set only Best values and not Worst.


    I am new in this API, and can't answer compleatly on your question. But looks like we have only one service for request. So, you can advice to us not use quality attributes, isn't it?

    And only for more understanding of answear on my question "how we can inform our application what all data already requested and ready for use instead". wasin.waeosri advised store number of items which we requested and every time then onRefreshMsg or onUpdatehMsg calls we should calculate the namber of this call for the unique item and compare it with the stored value (number of requested items). But in real situation I can see that if I request data for the 40 items for example then I will receive may be 10 or a little bit more number of fresh data. So we finishing waiting data after one minute left instead to receiving all 40 (for example) responces (items). Overwise we should wait for the wole list of item wole day or may be more.


    Sorry for my English. If this is not understandable, please tell me, I will try to parafrase it.

  • umer.nalla
    umer.nalla

    Hi @anton.filimonov.ext

    The Qos functionality is applicable where a customer has access to multiple services with differing QOS levels - so they can specify the rates they are prepared to accept. If you have only a single source then setting the QOs is not applicable.

    With regards to your other question, when you registerclient() an instrument, you should always receive one of the following

    • an initial RefreshMsg for each valid instrument
    • a StatusMsg with Closed state for any invalid request (e.g. not licenced to the RIC, invalid RIC code or RIC not available for some other reason).

    So, if you count the number of RefreshMsg + Status Msg with Close stream state - this should provide a way of confirming when all instrument requests have been processed and responded to by the server.

    e.g.

    statusMsg.getState().getStreamState() == StreamState::ClosedEnum

    where StreamState::ClosedEnum indicates the Stream was closed.


    For the RefreshMsg - you should also only count if it is a Solicited Refresh Msg

    refreshMsg.getSolicited()

    to ensure it is the initial Refresh for an instrument - not a subsequent one (e.g. received after data recovery scenario).



Categories