question

Upvote
Accepted
36 0 2 4

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?

elektronrefinitiv-realtimeelektron-sdkrrtema-apielektron-message-apimulti-threading
icon clock
10 |1500

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

Upvote
Accepted
23k 22 9 14

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.

icon clock
10 |1500

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

Upvotes
36 0 2 4

@zoya.farberov

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.

icon clock
10 |1500

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

Upvotes
23k 22 9 14

@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

icon clock
10 |1500

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

Upvotes
13k 32 12 18

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.

icon clock
10 |1500

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

Click below to post an Idea Post Idea