New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarification on amqp_maybe_release_buffers usage #211
Comments
The recommendation for using these functions is to call one of after you're done using an amqp_frame_t, an amqp_method_t or returned to you by rabbitmq-c. e.g.,
Internally the library uses a memory pool for each channel. It allocates from this pool, expanding it as necessary to fulfill memory needs. The the memory is re-used after calling To be more direct: you don't have to call
No, I would include other RPC operations as well (e.g., queue.declare, exchange.bind). The message you're referencing on the email list is still largely applicable. The only thing that has changed since that was written is internally memory is now pooled on a per-channel basis. Calling |
|
Thanks! Is it possible to destroy (not release) buffer for specific channel rather than all destroying it for whole connections? I mean situation where we close specific channel and do not intended it to use later, but there are pre-allocated buffer which still takes memory. Can you also consider how safe is to do such things while there are some chance that client and server channels list may be out of sync which channels are opened? |
|
rabbitmq-c does not provide a public API to free a memory pool for a channel (or even connection-wide). It not all that dangerous to free a memory pool for a channel that is potentially still open - memory pools are created on demand. The only noticeable effect would be performance, and even that wouldn't be huge on most systems with a reasonable malloc implementation. I would need to think carefully about what a reasonable API for this would be. Having both an |
|
When I have amqp_maybe_release_buffers, I get message header corruption at some random point. |
|
I found my bobo... wasn't checking presence of AMQP_BASIC_HEADERS_FLAG... now I am, and it's fine... |
Hi Alan,
could you provide some details on
amqp_maybe_release_buffers(as well asamqp_maybe_release_buffers_on_channel) usage?Does library utilize buffers in continuous
amqp_simple_rpccalls one by one or is it necessary to callamqp_maybe_release_buffersafter eachamqp_simple_rpc?Am I right that it is good idea to call
amqp_maybe_release_buffersonly after dealing with potentially large read operations, say afterbasic.get-ok,basic.return,basic.deliverprocessing?Maybe I'm missing something else, so if you will have time - highlight the intended usage of this function.
Thanks!
P.S.: I saw this mailing list discussion http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2013-June/027986.html but it is a bit old, so please give a note about whether all whitened there still valid or invalid.
The text was updated successfully, but these errors were encountered: