Offstream post returns Error Text channel out of buffers errorId=-4 errorText=channel out of buffers
Creating an offstream post for > 5000 instruments fails with
Error Text channel out of buffers errorId=-4 errorText=channel out of buffers.
For a long running application that takes post requests an OmmConsumer is created
A login is requested and after the Login refresh message 5000 post messages are triggered
after each post the PostMsg is cleared.
Then we get
Error Text channel out of buffers errorId=-4 errorText=channel out of buffers
The Guranteed buffer size is set to 5000 in Ema config.
Hello @niz,
As you appear to run out of guaranteed buffer space per your channel, my point was, to try to determine the reasonable setting for your custom posting consumer. There is no max supported number- see EMA Configuration Guide. This number times maxFragmentSize will be the buffer space in bytes available for your connected channel. Keeping large unnecessary buffers is wasteful, and may lead to consumer being slow, so usually we gauge the config required against the app requirements.
Running out of the buffer space is undesirable, but will not result in a memory leak, rather, in the more recent versions of SDK ( are you on 1.5 or 2.0? that would be preferable as many important fixes has been applied since the older versions), it just results in an error that you have seen.
Are you able to adjust and to proceed?
Hello @niz,
I would try to tune config for the use case, by first succeeding on a smaller post, and then making work the larger post that you require. I would post the same fields for a single instrument, and make sure the post succeeds. Once the post succeeds, grow by increment. Once you narrow down where the post starts failing, you may wish to increase the guaranteed output buffers to make sure the request succeeds again, till you arrive at the required 5000 instruments posted successfully.
There is a possibility, although less likely, because in this case you see the specific error message on the lack of acknowledgement, that this may be related to the recipient of the post, the recipient (custom provider or infra?) needs to support posting, and this specific post needs to be acknowledged by the recipient as valid.
Thanks, 5000 is not the required, the number could be more, so shall we then have a max supported number?
Also if the same consumer is being used subsequent requests with the same amount accumulate and the guaranteed value is no longer enough, could this be a memory leak?
will Run some test cases and evaluate, thanks