Balancing Event Queue messages

Hello,
We have a C++-developed Excel Add-in that provides UDF functions to users, which internally connects to RFA to fetch market data. RFA version 8.2.4.
Recently, multiple users have been experiencing a memory spike issue, where the memory climbs to a large size when the APIs are called from Excel. We noticed that the event queue is piling up with several messages waiting to be processed, nearly rising to 70 million. Since ours is a slow consumer, this is causing the memory size to grow larger. To balance this, could you please suggest if any RFA configuration settings need to be adjusted, such as: \Control\MessagePools\OMMItemEventPool\InitialSize \Control\MessagePools\OMMItemEventPool\Increment

Find more posts tagged with

c++

rfa

memory

event-queue

#technology

Accepted answers

All comments

Jirapongse

@Vikram_kumar26

Thank you for reaching out to us.

RFA C++ is designed to retrieve all real-time streaming data of subscribed items. If the application consumes events slowly, the event queue size can become significantly large.

There is no configuration to limit the number of events retrieved. However, you can use the following settings to control the behavior of the event queue.

Jirapongse

@Vikram_kumar26

I found that you can use the Maximum Depth Configuration, as mentioned in the section: 10.1.5.1 Maximum Depth Configuration.

An application can be notified that an event queue has reached the maximum depth.
Applications can use the setEventQueueMaxDepth() method to specify the maximum number of events allowed in the event
queue. The maxDepth argument must be greater than 0. (A maxDepth of 0 disables the functionality, allowing the queue to behave
like a normal event queue.)
To protect the application from exhausting memory, all events, including those for generic messages, are discarded when the event
queue maximum depth is reached. Any events already enqueued before the event queue maximum depth is reached remain in the queue. To process remaining events, the application can call dispatch as usual.
It is the application’s responsibility to perform any recovery after reaching the event queue maximum depth. During the recovery process, the application must call resetEventQueue() to tell the event queue to restart queuing events. Otherwise the event queue will not restart queuing events again

For more information, please refer to the section 10.1.5 Event Queue with Statistics in the RFA Developer Guide.

Vikram_kumar26

Hi,
Thanks for your quick response. I've made a note of the suggestions.
Also, I would like to mention that we had never faced this issue before and it was working fine for a long time, with no code changes made from our side.
Recently, over the past 3-4 weeks, we have been facing this issue. So, I would like to confirm if there were any changes made on the MDATA provider side?

Jirapongse

@Vikram_kumar26

This forum is intended for addressing questions related to API usage. For verification on the provider side, please contact the product support team directly through LSEG Support.

The size of the event queue typically depends on the number of subscribed items and their update rate. The update rate is not constant and may vary during periods of high market activity.

EXPLORE OUR SITES