I&#39;ve whipped up a pair of python scripts that demonstrate the issue.  They&#39;re using the queue-per-request anti-pattern, as that is what my production code is using  (if I can only get more time...)<div><br></div><div>
My test environment is 2 ubuntu 11.04 server boxes with erlang R14b03.  I have no plugins on a clean install of rabbit 2.5.0.  There are  2 nodes in my cluster, A and B.  A is a disc node, B is a ram node.  I run echo.py on the ram node, and spew.py on the disc node.  Each python script connects to its local broker.  I&#39;m using python-amqplib 0.6.1-1 for these scripts, though my production code is java based.  The &quot;guest&quot; account is set as an administrator on vhost /.  On my setup, the LATEST.LOG grows decently fast, maybe 15 meg an hour.</div>
<div><br></div><div>If there is something pathological in my scripts, I&#39;d love to hear it (beyond the aforementioned anti-pattern)... it is entirely possible I&#39;m not releasing a resource I guess.  Also, I&#39;m using basic_get() as it avoids the complexity of threading logic in the example, in production I use consumers.</div>
<div><br></div><div>tarball md5 is 1591ebbb1e9cffa06e6aec1c1ecb7b1d</div><div><br></div><div><br><br><div class="gmail_quote">On Wed, Jun 22, 2011 at 6:37 AM, Matthias Radestock <span dir="ltr">&lt;<a href="mailto:matthias@rabbitmq.com">matthias@rabbitmq.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Chris,<div class="im"><br>
<br>
On 22/06/11 11:25, Matthew Sackman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Jun 21, 2011 at 11:18:36AM -0400, Chris Madden wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I upgraded our erlang version to R14B03, but the LATEST.LOG still<br>
continues to be growing, albeit, more slowly perhaps?<br>
</blockquote>
<br>
Curious.<br>
</blockquote>
<br></div>
Are you sure that you haven&#39;t perhaps got a growing list of queues? Check with &#39;rabbitmqctl list_queues&#39;. Or, even better, use the fancy new &#39;rabbitmqctl report&#39; to produce a complete report of the server status and send that to us.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;m kind of suspicious of one of the queue usage models I&#39;m using.<br>
When one of the processes needs to make a one-off request (rpc<br>
like), it creates a queue dedicated to that request, and expects<br>
the reply to come back on that queue.<br>
</blockquote></blockquote>
<br></div>
Generally, &quot;queue per request&quot; is a design anti pattern. Though if your processes are short-lived and don&#39;t make many requests it&#39;s ok.<br><font color="#888888">
<br>
<br>
Matthias.</font><div><div></div><div class="h5"><br>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<u></u>rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
</div></div></blockquote></div><br></div>