Discover Refinitiv
MyRefinitiv Refinitiv Perspectives Careers
Created with Sketch.
All APIs Questions & Answers  Register |  Login
Ask a question
  • Questions
  • Tags
  • Badges
  • Unanswered
Search:
  • Home /
  • TREP APIs /
  • RFA /
avatar image
Question by ganesh.shivshankar · Feb 20, 2018 at 09:42 AM · rfaOMMclientommmsg

OMMMsg uniqueness

Hi,

I notice that the OMMMsg being received as part of the updates, most of then than not, seem to have same hashcode even though their attributes indicate that belong to different RICS. In my case I subscribe to a couple of RICS in the same DDS and I notice that 50-70% of the time the OMMMsg's hashcodes are the same for the updates.

OMMMsg msg = event.getMsg();

Is this an intended behavior? How do we get around this?

Thanks.

Regards,

Ganesh

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.

7 Replies

  • Sort: 
avatar image
REFINITIV
Best Answer
Answer by David Thomas · Feb 22, 2018 at 10:36 AM

Hello @ganesh.shivshankar

As you will need a deep copy for what you are doing, OMMPool.acquireCopy(OMMData) is not suitable and I suggest you use the OMMMsg.initFrom(OMMMsg) but do keep in mind that if/when you release these objects back to the OMMPool they will re-appear with the same hashCode when they are re-used.

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.

avatar image
REFINITIV
Answer by Gurpreet · Feb 20, 2018 at 10:13 AM

Hi @ganesh.shivshankar. The OMMMsg above is owned (created, managed and released) by the RFA API and API can reuse the same container to pass on different messages to the application. This is done to optimize memory management - which is why you are getting same hash for multiple updates.

To distinguish between updates from different subscriptions, the app can:

  1. Enable (set ATTRIB_INFO_IN_UPDATES indication flag) and check Attribute Information (OMMAttribInfo) for ServiceName/Item Name combination
  2. Or pass on a custom object as a closure when subscribing. This object is passed back to app in the processEvent callback.
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.

avatar image
Answer by ganesh.shivshankar · Feb 20, 2018 at 10:20 AM

Thanks for the quick response! This is causing problems for us as we are trying to hold the incoming OMMMsgs in a queue and process the messages in a separate queue altogether (so as to not block the rfa thread as we have highly volatile RICs being subscribed to). So it results in objects being overridden one for the other. So we have resorted to do a deep copy of the OMMMsg using initFrom and put that into our queue, but we are not sure of the implications of doing this. Is this recommended?

Comment

People who like this

0 Show 1 · 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.

avatar image
REFINITIV
Gurpreet ♦♦ · Feb 20, 2018 at 10:38 AM 0
Share

The event queue dispatch thread is owned and controlled by the user application. So RFA thread will not be blocked, when the user is processing the events.

The memory impact of holding the object in RFA event queue vs. deep copying will be same. If the application does not process messages fast enough, it will eventually run out of heap memory.

avatar image
REFINITIV
Answer by David Thomas · Feb 20, 2018 at 10:26 AM

Hello @ganesh.shivshankar

As the hashCode() method is supported for the benefit of hash tables you should note that the objects passed to the the Client interface by the API belong to the API, they will be reclaimed when the processEvent method has returned and potentially recycled by the API (The exception to this rule is the closure argument). Therefore you should not attempt to store these objects.

The closure argument is supplied by your application when you register the client and is contained in any event received as a result of registering that client interest - could this satisfy your requirement?

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.

avatar image
Answer by ganesh.shivshankar · Feb 20, 2018 at 10:30 AM

The closure (we have this in place already) does give us a context for the incoming message, but we have a some business logic to perform on the messages as they arrive, which is slightly processing intensive and could block the event queue thread and hence we want to defer that to a different thread. Would storing the payload (msg.getPayload()) from the message in a queue help in this case, instead of storing the entire OMMMsg object? I see that the hashcode of the payload is always different.

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.

avatar image
REFINITIV
Answer by David Thomas · Feb 20, 2018 at 10:38 AM

If you do not need the entire image you should find it more efficient to copy out the fields you require (assuming MP model) and potentially reduce the workload further by using views.

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.

avatar image
Answer by ganesh.shivshankar · Feb 20, 2018 at 10:42 AM

We do filter out what we need using views, but we still need to defer the parsing of the payload to a different thread, in order to avoid blocking the event queue. We use the OMM model. So would storing the payload (OMMData) work here or is that not recommended either?

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 >
12 People are following this question.

Related Questions

RSSL buffer failed

Unable to get rid of garbage

Bad directory data with multiple clients

Omm mock Tests

How can I use the SymbolList domain to get a RIC listing for a venue on Elektron RT? In my case, specifically for the TSE Equities market?

  • Feedback
  • Copyright
  • Cookie Policy
  • Privacy Statement
  • Terms of Use
  • Careers
  • Anonymous
  • Sign in
  • Create
  • Ask a question
  • Spaces
  • Alpha
  • App Studio
  • Block Chain
  • Bot Platform
  • Calais
  • Connected Risk APIs
  • DSS
  • Data Fusion
  • Data Model Discovery
  • Datastream
  • Eikon COM
  • Eikon Data APIs
  • Elektron
    • EMA
    • ETA
    • WebSocket API
  • Legal One
  • Messenger Bot
  • Messenger Side by Side
  • ONESOURCE
    • Indirect Tax
  • Open PermID
    • Entity Search
  • Org ID
  • PAM
    • PAM - Logging
  • ProView
  • ProView Internal
  • Product Insight
  • Project Tracking
  • 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
  • TRIT
  • TRKD
  • TRTH
  • Thomson One Smart
  • Transactions
    • REDI API
  • Velocity Analytics
  • Wealth Management Web Services
  • World-Check Data File
  • Explore
  • Tags
  • Questions
  • Badges