How can I get updates to an instrument at a set interval

Attempt 1 - QoS

I noticed in the API that there is setQos and setQosReq methods in OMMMsg, however when I set that value it doesn't seem to do anything (i.e. its never transmitted to the provider). I tried running the provider in the demo where it logs out the message and it was always set to QoS of realtime, tick by tick.

Looking further into it, the interactive provider (com.reuters.rfa.example.omm.prov.StartedProvider_Interactive) sets an array of QoS in the directory that is returned to the consumer. The QoS always equalled the first element of that array no matter what I set it to or what I requested in the OMMMsg. I also noticed that if I returned an empty array as part of the directory then it would set no QoS. I feel like I must be doing something wrong.
Note that I want to be able to set the QoS as we have 2 sets of instruments one that needs to be updated in real time and the other (very large set) that needs to be updated every few seconds, so I want to be able to set different QoS for different instruments.

I am using RFA Java 8.0.1

EDIT - Attempt 2 - Pause & Resume

So after the feedback from the responses to the first question to say that QoS is not possible, I am attempting to use the pause and resume feature so that I pause the stream at regular intervals then resume for a short period and pause it again. However when I set the indication on the consumer of PAUSE_REQ it does not get sent to the provider either.

EDIT2 - Seems pause/resume is not supported on the server I'm running otherwise it would work.

End Edit - note below is from the original - its just not possible to add lines after a code block for some reason in this editor...

Here is some sample code for the QoS request that is being sent:

private Handle register(Client client, EventQueue queue, String serviceName, String itemName, boolean streaming, short msgModelType, byte priorityClass,
            int priorityCount) {
    OMMMsg msg = this._pool.acquireMsg();
    msg.setMsgType(OMMMsg.MsgType.REQUEST);
    if (!streaming) {
        msg.setIndicationFlags(OMMMsg.Indication.NONSTREAMING | OMMMsg.Indication.REFRESH);
    } else {
        msg.setIndicationFlags(OMMMsg.Indication.REFRESH);
    }
    // TODO Qos seems to be ignored by the RFA.. it reads the first entry 
    // in the directory for the service. 
    // It is saved in RDMServiceInfo but can't figure out how to retrieve 
    // it and modify it on the fly...
    msg.setQos(OMMQos.QOS_REALTIME_JIT);
//    msg.setQos(0, this._intervalRate);
    msg.setMsgModelType(msgModelType);
    msg.setAttribInfo(serviceName, itemName, RDMInstrument.NameType.RIC);
    if (priorityClass + priorityCount > 0) {
        msg.setPriority(priorityClass, priorityCount);
    }
    this._spec.setMsg(msg);
    Handle handle = this._ommConsumer.registerClient(queue, this._spec, client, null);
    this._pool.releaseMsg(msg);
    return handle;
}

Find more posts tagged with

trep

rfa

OMM

qos

rfa-api

Accepted answers

Jonathan Haruni - Refinitiv

The QoS feature of the API allows you to select between available variants of a service within an infrastructure, if they are available. It does not allow you to modify the QoS of any service. In most places there is only one QoS available for a service, e.g. full streaming real time data. Assuming your situation is typical, you probably shouldn't be using this feature of the API to do what you want.

Sometimes there is more than one QoS, for example Thomson Reuters offers delayed and conflated services through EMS, and some large banks offer this internally to their users. In these cases, the different QoS services are usually made available on an entirely different service name (EG MY_SERVICE and MY_SERVICE_DELAYED) rather than using this API feature.

If you're working with Thomson Reuters to implement an application with EMS, you should talk to your Technical Account Manager about how to connect to both real-time and conflated services.

If you're writing an application that needs to work in many environments (e.g. various banks), where different levels of service may or may not be available, the way to do it is as follows: Define two services in your application with different configurable service names, and draw your subscriptions from the appropriate one. While planning any implementation you need to ensure it will have access to services with the appropriate QoS. If it would be acceptable for both of your services to be configured to the same real-time data source, you should allow that for flexibility.

All comments

Nipat Kunvutipongsak

@kevin.mak In case of RFA Java consumer application, it always sends static QoS (Real-time Tick-by-Tick) to the server regardless any values in the request message. So, the settings in the request message object have no effects in the outgoing message to the server because the underlying layer normally manages QoS automatically by selected the best QoS available channel on behalf of the application layer.

That's why it is different between consumer and provider function.

Jonathan Haruni - Refinitiv

If you're working with Thomson Reuters to implement an application with EMS, you should talk to your Technical Account Manager about how to connect to both real-time and conflated services.

kevin.mak

Thanks Nipat, I understand now that QoS is not available, however I am now trying Pause/Resume and that doesn't seem to work either (see edit in original question) .... - nevermind just saw that the server I'm using doesn't support pause/resume. Thanks for the response.

kevin.mak

Thanks Jonathan, I understand now that QoS is not available, however I am now trying Pause/Resume and that doesn't seem to work either (see edit in original question) .... - nevermind just saw that the server I'm using doesn't support pause/resume. Thanks for the response.

zoya faberov

@kevin.mak

To find out if pause/resume is supported by your infrastructure, please review your initial login response. You should see something like

ELEMENT_ENTRY SupportOptimizedPauseResume: 1

ELEMENT_ENTRY SupportPauseResume: 1

I think that using pause/resume to control the quality of service is not right. My understanding is you would like to receive periodic updates. Instead, maybe running snapshot requests at a specific interval would be better suited for your use case?

kevin.mak

@zoya.farberov Thanks for the reply. I noticed in the logs that a warning is printed saying that pause/resume is not supported for our server, which I'm investigating separately with TR.

I was attempting to use pause/resume simply because the dev guide had a similar scenario to us where it suggested pausing a request when an instrument is not visible on the page then resuming it again when the instrument is visible.

I'm looking at doing the snapshots as a backup, I just figured that pause/resume would result in less data transfer as it is only the fields that changed.

zoya faberov

@kevin.mak

You are right in that both approaches should be considered.

The better choice depends on your use case, how often you need the snapshots and how large is the data set of interest, these considerations should drive your choice.

You prefer not to have huge set of subscriptions to be maintained by the infra all the time when you only need the images rarely, or for only few out of a large subscribed set. In this case snapshot is a clear winner.

And you do not want to snapshot several times per second, in this case pause/resume may be a better choice, as the overhead of pause/resume is smaller.

The third possibility, rarely used, is to conflate yourself, at the application level. It's better to be able to access a conflated service, but is not always possible, or the level of conflation that's available may not be right for your app. If the extra processing is not a problem for the app, this may be a preferrable choice too.

EXPLORE OUR SITES