Discover Refinitiv
MyRefinitiv Refinitiv Perspectives Careers
Created with Sketch.
All APIs Questions & Answers  Register |  Login
Ask a question
  • Questions
  • Tags
  • Badges
  • Unanswered
Search:
  • Home /
  • Elektron /
  • EMA /
avatar image
Question by paz.barda · Feb 09, 2020 at 09:22 AM · elektronrefinitiv-realtimeelektron-sdkrrtema-apielektron-message-api

Getting an ad-hoc RefreshMsg while stream is open

TLDR - java consumer app, trying to find the best way to get on-demand/adhoc RefreshMsg for couple of K RICS every few minutes.


Hi,

We're developing a java consumer application. one of the requirements is to make sure that for every RIC we're tracking (~10K), our data is no older than X minutes. this means that for every RIC that did not get UpdateMsg within the past X minutes, we'd like to get an on-demand/adhoc RefreshMsg.

what would be the best way (=cleanest and most efficient) to initiate a RefreshMsg on an already-open stream?

app-specific details:

> pom:

<dependency>
    <groupId>com.thomsonreuters.ema</groupId>
    <artifactId>ema</artifactId>
    <version>3.4.0.0</version>
</dependency>

> our registration to OmmConsumer is based on View (we are interested in only ~20 fids):

private ReqMsg getViewReqMsg(String symbol) {
    OmmArray fidsArray = EmaFactory.createOmmArray();
    supportedFIDs.forEach(fid -> fidsArray.add(EmaFactory.createOmmArrayEntry().intValue(fid)));
    ElementList viewElementList = EmaFactory.createElementList();
    viewElementList.add(EmaFactory.createElementEntry().uintValue(EmaRdm.ENAME_VIEW_TYPE, 1));
    viewElementList.add(EmaFactory.createElementEntry().array(EmaRdm.ENAME_VIEW_DATA, fidsArray));
    return EmaFactory.createReqMsg()
            .name(symbol)
            .serviceName(service)
            .payload(viewElementList);
}

> this is how we are registering to each symbol initially:

private void registerAllSymbols(OmmConsumer consumer) {
    symbols.forEach(symbol -> {
        ReqMsg reqMsg = getViewReqMsg(symbol);
        symbolNameToLoginHandle.put(symbol, consumer.registerClient(reqMsg, appClient));
    });
}


> now, when acting upon an 'expired' RIC, this is what we've tried:

Option A: reissue

private Consumer<F> getExpiredSymbolStateHandler(OmmConsumer consumer) {
        return expiredSymbolState -> {
            String symbolName = expiredSymbolState.getSymbolName();
            ReqMsg reqMsg = getViewReqMsg(symbolName);
            consumer.reissue(reqMsg, symbolNameToLoginHandle.get(symbolName));
        };
    }

for some reason, this does not seem to have any effect (we're not getting RefreshMsgs, although UpdateMsgs are received so we know the stream for that RIC is still alive).

Option B: (re)register

private Consumer<F> getExpiredSymbolStateHandler(OmmConsumer consumer) {
        return expiredSymbolState -> {
            String symbolName = expiredSymbolState.getSymbolName();
            ReqMsg reqMsg = getViewReqMsg(symbolName);
            symbolNameToLoginHandle.put(symbolName, consumer.registerClient(reqMsg, appClient));
        };
    }

this seems to work fine whenever the ReqMsg is 'simple' (= no View is involved), but this means getting all fids, which is undesired. when doing the same with View (getViewReqMsg(String symbol) above) we start getting double messages, as if the 2nd register operation opened a new stream on top of the existing one (also undesired, of course)

Option C: unregister + (re)register --> BEST WE GOT SO FAR

private Consumer<F> getExpiredSymbolStateHandler(OmmConsumer consumer) {
        return expiredSymbolState -> {
            String symbolName = expiredSymbolState.getSymbolName();
            ReqMsg reqMsg = getViewReqMsg(symbolName);
            consumer.unregister(symbolNameToLoginHandle.get(symbolName));
            symbolNameToLoginHandle.put(symbolName, consumer.registerClient(reqMsg, appClient));
        };
    }

this works fine, but it feels like an overkill when doing it on several Ks of RICs every couple of minutes -- especially when there seem to be more natural options available in the API (like Option A).

obviously we're missing something with options A and B, any thoughts?

Thanks :)

People who like this

0 Show 0
Comment
10 |1500 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

1 Reply

  • Sort: 
avatar image
REFINITIV
Best Answer
Answer by Jirapongse · Feb 11, 2020 at 07:53 AM

@paz.barda

Option A should be the optimal one to get the lastest refresh message.

From my testing, for reissuing with the same view, the view data can be ignored. Therefore, the code for reissue could be:

private Consumer<F> getExpiredSymbolStateHandler(OmmConsumer consumer) {
        return expiredSymbolState -> {
            String symbolName = expiredSymbolState.getSymbolName();
            ReqMsg reqMsg = getViewReissueReqMsg(symbolName);
            consumer.reissue(EmaFactory.createReqMsg(), symbolNameToLoginHandle.get(symbolName));
        };
    }
Comment

People who like this

0 Show 0 · Share
10 |1500 characters needed characters left characters exceeded
▼
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Watch this question

Add to watch list
Add to your watch list to receive emailed updates for this question. Too many emails? Change your settings >
7 People are following this question.

Related Questions

Login Domain - Components and Elements in Login responses

(JAVA) Does using interestAfterRefresh(false) remove the need for deregistering items with Elektron?

EMA CPP - Exception adding ric into OmmArray

EMA OmmConsumer memory leak in Java API?

EMA Batchview: Getting data for fields in updates that I did not specify

  • Copyright
  • Cookie Policy
  • Privacy Statement
  • Terms of Use
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Spaces
  • Alpha
  • App Studio
  • Block Chain
  • Bot Platform
  • Connected Risk APIs
  • DSS
  • Data Fusion
  • Data Model Discovery
  • Datastream
  • Eikon COM
  • Eikon Data APIs
  • Electronic Trading
    • Generic FIX
    • Local Bank Node API
    • Trading API
  • Elektron
    • EMA
    • ETA
    • WebSocket API
  • FX Venues
    • FX Trading – RFQ Maker
  • Intelligent Tagging
  • Legal One
  • Messenger Bot
  • Messenger Side by Side
  • ONESOURCE
    • Indirect Tax
  • Open Calais
  • Open PermID
    • Entity Search
  • Org ID
  • PAM
    • PAM - Logging
  • ProView
  • ProView Internal
  • Product Insight
  • Project Tracking
  • RDMS
  • Refinitiv Data Platform
    • Refinitiv Data Platform Libraries
  • Rose's Space
  • Screening
    • Qual-ID API
    • Screening Deployed
    • Screening Online
    • World-Check One
    • World-Check One Zero Footprint
  • Side by Side Integration API
  • TR Knowledge Graph
  • TREP APIs
    • CAT
    • DACS Station
    • Open DACS
    • RFA
    • UPA
  • TREP Infrastructure
  • TRKD
  • TRTH
  • Thomson One Smart
  • Transactions
    • REDI API
  • Velocity Analytics
  • Wealth Management Web Services
  • Workspace SDK
    • Element Framework
    • Grid
  • World-Check Data File
  • Yield Book Analytics
  • 中文论坛
  • Explore
  • Tags
  • Questions
  • Badges