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.

@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.

@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

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.