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

[Alexandru Scvortov]

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

'Ram' nodes will not have any *mnesia* files on disk anymore.  Message
store files will still be there.

Alex

On Fri, Jul 29, 2011 at 02:49:54PM +0100, Alexandru Scvorţov wrote:
> 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
>