<div dir="ltr">SimpleAmqpClient should call MaybeReleaseBuffersOnChannel, which if it has no frames enqueued, should call amqp_maybe_release_buffers_on_channel(), which if rabbitmq-c doesn't have any frames lying around will recycle the pool associated with that channel. If this really is a bug (possible...) it would be good to know which channel(s) SimpleAmqpClient is publishing on, and which channel(s) are growing without bound (e.g., which entry in amqp_connection_state_t.pool_table).<div>
<br></div><div>-Alan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 3, 2014 at 5:19 PM, Dushin Fred <span dir="ltr"><<a href="mailto:fred@dushin.net" target="_blank">fred@dushin.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>I have written a simple test program using the SimpleAqmpClient library (which in turn uses the rabbitmq-c library), which seems to illustrate a memory leak, of sorts.</div>
<div><br></div><div>The program is a simple main, which pre-allocates a string message, and then calls BasicPublish on a channel in a loop, all single threaded. Effectively:</div><div><br></div><div><div style="margin:0px;font-size:11px;font-family:Menlo">
<span style="color:#bb2ca2">auto</span> envelope = <span style="color:#703daa">BasicMessage</span>::<span style="color:#3d1d81">Create</span>(<span style="color:#31595d">random_data</span>(message_size));</div><div style="margin:0px;font-size:11px;font-family:Menlo">
<span style="color:#bb2ca2">for</span> (<span style="color:#bb2ca2">unsigned</span> i = <span style="color:#272ad8">0</span>; i < num_messages; ++i)</div><div style="margin:0px;font-size:11px;font-family:Menlo">
{</div><div style="margin:0px;font-size:11px;font-family:Menlo"> channel-><span style="color:#3d1d81">BasicPublish</span>(exchange_name, routing_key, envelope);</div><div style="margin:0px;font-size:11px;font-family:Menlo">
}</div></div><div><br></div><div>The problem is that the memory image of this process seems to grow without bounds. The memory all seems to be allocated in amqp_pool_alloc (as expected), when calling wait_frame_inner -> amqp_handle_input. The memory is not orphaned -- i.e., it seems to get cleaned up at shutdown, so it doesn't show up as a leak in a leak detector tool, such a Instruments/DTrace, or valgrind, or purify, etc. But I don't see where the memory is every de-allocated, which will spell doom for an application that is designed to never terminate.</div>
<div><br></div><div>I am attaching a screenshot from an Instruments run, to give some context. The code is here:</div><div><br></div><div><a href="https://github.com/fadushin/sandbox/blob/master/cpp/rabbitmq/sender.cpp" target="_blank">https://github.com/fadushin/sandbox/blob/master/cpp/rabbitmq/sender.cpp</a></div>
<div><br></div><div>This was run against RabbitMQ 3.2.4, using rabbitmq-c 0.5.0 and SimpleAmqpClient 2.3, compiled using Clang 5.0 on OS X.9 (Mavericks).</div><div><br></div><div>Has anyone seen this behavior? Am I missing something in my use of BasicPublish, that is not telling the rabbitmq-c library to free memory in the "amqp pool"? It doesn't seem to make a difference whether I am actively pulling messages off the queue from a separate process, or even whether there is a queue bound to the exchange to which I am publishing messages. (Not that I would expect it to)</div>
<div><br></div><div>-Fred</div><div><br></div><div>encl.</div><div><br></div><div><br></div><div><img height="545" width="897" src="cid:9DBB6641-0A1A-4374-9788-CFF34265600A@corp.emc.com"></div></div><br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br></div>