I've whipped up a pair of python scripts that demonstrate the issue. �They'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'm using python-amqplib 0.6.1-1 for these scripts, though my production code is java based. �The "guest" 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'd love to hear it (beyond the aforementioned anti-pattern)... it is entirely possible I'm not releasing a resource I guess. �Also, I'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"><<a href="mailto:matthias@rabbitmq.com">matthias@rabbitmq.com</a>></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't perhaps got a growing list of queues? Check with 'rabbitmqctl list_queues'. Or, even better, use the fancy new 'rabbitmqctl report' 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'm kind of suspicious of one of the queue usage models I'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, "queue per request" is a design anti pattern. Though if your processes are short-lived and don't make many requests it'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>