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 joe.hong · Oct 10, 2017 at 03:01 PM · elektronezdemaj

OmmConsumer registerClient single-threaded?

Does anyone know if the OmmConsumer.registerClient() method is single threaded? The reason for the question is during load testing of our application (EMAJ connecting to EZD), when running a single user (single client), the application runs fine for 1000 iterations at 5 second intervals.

But when we start introducing additional users at random intervals, it looks like requests are fighting for the registerClient resource, causing timeouts and reactor being shut down randomly.

We've been facing this issue in our Production environment and cannot pinpoint the issues we're experiencing. In our Production environment, we have many concurrent requests from all different sources and issues start occurring under heavy load.

Any assistance will much appreciated.

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.

3 Replies

  • Sort: 
avatar image
Best Answer
Answer by Michal Frajt · Nov 21, 2017 at 05:04 AM

Hi @joe.hong,

unfortunately the EMA OMMConsumer public methods are using very primitive synchronization of a monitor/lock around nearly the complete method body. It is actually very close to have all methods simply synchronized. There is no level of concurrent processing if you call registerClient() from several threads. It could be still somehow acceptable as a simplification but it is not acceptable that the same monitor/lock is used around reading messages from the Reactor channel. More you register, more messages you are receiving, more contention happens between register/unregister/submit methods and the message reading. This design is way away from the RFA API which was/is providing several concurrency models where you could have a dedicated request queue for the register/unregister/submit methods which guaranteed instant processing as there was no contention with the message processing part. This design is actually returning us back to 90´s where the SSL Classic C API was using similar threading model implemented by a global mutex around all C API methods including the dispatch call.

It could be just a bug as there is actually not much need to use the _userLock around the dispatchAll call as the reactor is using its global _reactorLock anyway. But removing the _userLock would not help much as the register/unregister/submit methods are still speaking to the Reactor methods where the _reactorLock is requested anyway. The locking model between the Reactor and OMMConsumer is then very questionable, using basic lock/unlock to protect every method looks old school in the time where other API’s are using techniques like out-of-thin-air/relax reads, spinning, CAS, optimistic reads, memory fences, etc.

Dispatch
{
_userLock.lock();
ret = _rsslReactor.reactorChannel()!= null? _rsslReactor.dispatchAll(null, rsslDispatchOptions, _rsslErrorInfo) : ReactorReturnCodes.SUCCESS;
_userLock.unlock();
}

Register
try {
_userLock.lock();
long handle = _itemCallbackClient != null ? _itemCallbackClient.registerClient(reqMsg, client, null, 0) : 0;
return handle;
} finally {
_userLock.unlock();
}

Best regards,
Michal Frajt

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 wasin.waeosri · Oct 11, 2017 at 04:45 AM

Hi @joe.hong

Based on the API reference guide, the OmmConsumer.registerClient() method is Object Level Safe.

Object Level Thread Safe Method

Multiple application threads of control may concurrently call this method on the same instance. Applications will, however, incur the cost of synchronization overhead (e.g., blocking) while calling this method. By synchronizing concurrent access to this method on per instance basis, EMA preserves the state of individual instances and resolves any race condition that may arise while multiple application threads of control concurrently call this method on the same instance.

Regarding the problem, does the application create multiple OmmConsumer instances for each request? What is a version of EMA Java that encounters the problem? Can you replicate the issue in the non-production environment?

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
joe.hong · Oct 11, 2017 at 08:55 AM 0
Share

The application creates one OmmConsumer object that is re-used for all registerClient calls. The version of EMAJ is 1.1.0. Yes, we can replicate the issues in our non-production environment.

avatar image
REFINITIV
Answer by wasin.waeosri · Oct 12, 2017 at 06:39 AM

Hi @joe.hong

You can submit this problem to developer directly via Github at https://github.com/thomsonreuters/Elektron-SDK/issues link.

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

Related Questions

I need to move the parameters of OmmConsumerConfig(0 into a configuration file. I understand that the username is of type const thomsonreuters::ema::access::EmaString. How can I convert a cpp string to that data type?

How to Post with EMA C++

Is there any unique identifier for a news item ?

NIProvider using RSSL_SOCKET over SSL: unable to publish data

The connection between my application and the Reuters Centers died again, I can't receive quotaion now. And the application can't reconnect itself.

  • 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