Multi threading

For multi threading we were looking into example 410. However in this example different users are used to create multiple OmmConsumers. We would prefer a multi-threaded solution that works with only one user.

We tried creating multiple consumers using the same login, but that doesn't seem to work with the token refreshing. Another thing we tried was using a single Consumer with multiple threads calling the dispatch method. In this case it seems like the message decoding isn't really working parallel, probably due to locks in the dispatch method. So this doesn't really help when decoding is slow.

Is there any way to use multi threading with only one user?

Find more posts tagged with

elektron

elektron-sdk

refinitiv-realtime

rrt

multi-threading

elektron-message-api

ema-api

Accepted answers

zoya faberov

Hello @gerard,

Take a look at PerfTools code consumer example, found in Elektron Java SDK within

Java\Ema\PerfTools

Alternatively, an often-used approach is to dispatch from a single thread, however, immediately hand-over any heavy processing to another worker thread, usually a member of a worker thread pool. If the required business processing is heavy compared to the dispatch, this approach to threading design is more commonly used.

All comments

zoya faberov

Hello @gerard,

Take a look at PerfTools code consumer example, found in Elektron Java SDK within

Java\Ema\PerfTools

gerard

@zoya faberov

I had a quick look a the PerfTools code. It seems like one of the solutions I've tried, multiple OmmConsumers with the same login, which caused problems with token refreshing. Note that I'm testing with ERT in Cloud. In the PerfTools code there's no password being used, so I guess this wasn't really designed for ERT in cloud and might behave differently when adjusting the code in order to use in. I will look further into this code.

The alternative approach you suggested was also a solution I've considered. This still leaves one part single threaded though. So if that part becomes too slow due to the amount of messages, the whole application will be too slow. But this currently seems to be the best option.

zoya faberov

@gerard

This is correct. The example predates ERT in Cloud, and was designed to test performance of EMA API, consuming from TREP (distribution system) or directly from a provider.

ETA includes both, consumer and provider, and one can run the provider and consume from it with consumer to performance-test EMA API.

Java\Eta\Applications\PerfTools

Gurpreet

Hi @gerard,

The ERT in cloud conflates the data to 3 updates/sec. The volume of data from cloud will be considerably less than, what would normally be consumed from a TREP source. A single threaded application, should be quite able to handle this reduced volume. If there is time consuming post-processing required on the data, then as per @Zoya's suggestion, hand-over any heavy processing to a worker thread.

EXPLORE OUR SITES