Can I get infomation of stored event in a event queue on EMA?

kotaro_okada

I'm trying to migrate my RFA API application to EMA/ETA API app.

In RFA, I can get the number of stored event in a event queue by rfa::common::EventQueue::getEventQueueCurrentSize(). I use this for evaluating the speed of event processing of my app.

In EMA, there are no event queue functions, so I want to know how should I evaluate the speed.

• Can I get the number of stored event in a event queue by another function?
• Can EMA API alert us that event queue is full or getting over some threshold?
• Is there any other ways to evaluate that my application is enough fast to process all events on time?

Jirapongse

@kotaro_okada

Thank you for reaching out to us.

EMA does not use an event queue. Instead, data is accessed directly from the API's internal buffer and the underlying TCP buffer. With EMA, applications receive data through the OmmConsumerClient callback methods. Therefore, it's crucial that these callbacks return quickly to prevent the application from becoming a slow consumer.

The application can also implement its own queue by cloning messages within the callback functions, extracting the necessary data, and placing either the extracted data or the cloned messages into a queue for processing by other threads.

wasin.w V3

Hello @kotaro_okada

This https://developers.lseg.com/en/article-catalog/article/rfa-to-ema-migration-notes article might help you too.

kotaro_okada

@Jirapongse

Thank you for your answers.

EMA does not use an event queue. Instead, data is accessed directly from the API's internal buffer and the underlying TCP buffer. With EMA, applications receive data through the OmmConsumerClient callback methods. Therefore, it's crucial that these callbacks return quickly to prevent the application from becoming a slow consumer.

If OmmConsumerClient callback return too slowly, data could be stacked on TCP buffer, and we can check it by some OS command like netstat, right?

@wasin.w V3

Thank you, I will check it.

Jirapongse

@kotaro_okada

You need to check the TCP receive window size of a consuming application. You can refer to this article.

Alternatively, some fields include timestamps. You can compare these with the time at which the fields are retrieved—if the gap is significant, it may indicate that the application is a slow consumer.

kotaro_okada

@Jirapongse

I understand, thank you!