[rabbitmq-discuss] LATEST.LOG growth on clustered ram node

Tue Jun 28 02:55:26 BST 2011

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...)

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.

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.

tarball md5 is 1591ebbb1e9cffa06e6aec1c1ecb7b1d

On Wed, Jun 22, 2011 at 6:37 AM, Matthias Radestock
<matthias at rabbitmq.com>wrote:

> Chris,
>
>
> On 22/06/11 11:25, Matthew Sackman wrote:
>
>> On Tue, Jun 21, 2011 at 11:18:36AM -0400, Chris Madden wrote:
>>
>>> I upgraded our erlang version to R14B03, but the LATEST.LOG still
>>> continues to be growing, albeit, more slowly perhaps?
>>>
>>
>> Curious.
>>
>
> 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.
>
>
>  I'm kind of suspicious of one of the queue usage models I'm using.
>>> When one of the processes needs to make a one-off request (rpc
>>> like), it creates a queue dedicated to that request, and expects
>>> the reply to come back on that queue.
>>>
>>
> 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.
>
>
> Matthias.
>
> ______________________________**_________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.**rabbitmq.com<rabbitmq-discuss at lists.rabbitmq.com>
> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110627/b49fdf42/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repro.tar.gz
Type: application/x-gzip
Size: 952 bytes
Desc: not available
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110627/b49fdf42/attachment-0001.bin>