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

Fri Jul 29 14:49:54 BST 2011

Chris,

A fix for this has landed on default earlier today and should be in the
next release.

Basically, we re-enabled disk-less nodes.  So, 'ram' nodes will not have
any files on disk anymore.

Thanks for reporting the problem.

Cheers,
Alex

On Mon, Jun 27, 2011 at 09:55:26PM -0400, Chris Madden wrote:
> 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>
> >

> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss