For a deeper look into our Elektron API, look into:
Overview | Quickstart | Documentation | Downloads | Tutorials | Articles
Failed to allocate RsslTunnelBuffer with EMA C++ post message
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?
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);
@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
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.
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.