For a deeper look into our Elektron API, look into:

Overview |  Quickstart |  Documentation |  Downloads |  Tutorials |  Articles

question

Upvotes
Accepted
ye.li avatar image
9 ●1 ●2 ●2

Failed to allocate RsslTunnelBuffer with EMA C++ post message

My application uses EMA C++ to post message to contribution channel.

When the app submitted a bunch of page message (25*80) in a very short time, i started to get the exceptions below saying there's memory exhaustion.

OmmException Internal Error. Failed to allocate RsslTunnelStreamBuffer in TunnelItem::submitSubItemMsg( RsslMsg* )., Type=OmmMemoryExhaustionException

I am trying to send out about 150 pages (25*80) at that time. If I remove those RICs from the posting list and restart the app, everything works okay.

is this memory exhaustion caused by the number of messages it sent out? Is there a limit on the message size and rate?

elektronrefinitiv-realtimeelektron-sdk
icon clock
10 |1500

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

3 Answers

Upvotes
Accepted
Jirapongse avatar image
56.3k ●145 ●45 ●65

@ye.li

It looks similar to the discussion in this thread.

For a tunnel stream, you may need to increase guaranteedOutputBuffers of TunnelStreamRequest.

TunnelStreamRequest tsr;
tsr.classOfService(cos).domainType(MMT_SYSTEM).name("Seikan").serviceName("DDS_TRCE");
tsr.guaranteedOutputBuffers(5000);
icon clock
10 |1500

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

Mike Slade avatar image Mike Slade

@jirapongse.phuriphanvichai - thanks for your reply

We can attempt to increase this limit in our application. Is 5000 the recommended number of output buffers? Also, the error seemed to persist even when our outbound traffic was greatly reduced. If this error occurs are the buffers never released? Thanks

Upvotes
umer.nalla avatar image
25k ●87 ●11 ●23

Hi @ye.li

The error you are seeing is most likely due to exhausting tunnel buffers.

Whilst increasing the tunnel buffers can help, if the messages are not being acknowledged quickly enough, it will eventually have a build of pending messages e.g. delays because of the network or buffers not being cleared fast enough by RCC server.

If the absolute timeliness of the posts is not critical, then you could pace/throttle the rate at which you are sending the posts - i.e. just spread the posts over a slightly longer time period. This should avoid the exhausting of the tunnel buffers.

Otherwise, the other option would be to pause the posting momentarily when you run out of buffers.

There are no hard and fast rules/numbers as too many factors would affect what would be a serviceable rate of posting, you will need to experiment to find a safe rate - and then allow a safety margin.

icon clock
10 |1500

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

Upvotes
Jirapongse avatar image
56.3k ●145 ●45 ●65

@Mike Slade

No, 5000 is not the recommended number of guaranteed output buffers. It proves that the problem relates to the size of the guaranteed output buffers. Typically, the guaranteed output buffer is quite small for the consumer application because the guaranteed output buffer is for outgoing messages and the consumer application doesn't publish data.

However, the contribution application may require more guaranteed output buffers than the consumer application. The tsr.guaranteedOutputBuffers() method can be used to increase the size of guaranteed output buffers of a tunnel stream.


icon clock
10 |1500

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