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

Chris Madden chris.madden at gmail.com
Wed Jun 22 15:14:43 BST 2011


On Wed, Jun 22, 2011 at 6:25 AM, Matthew Sackman <matthew at rabbitmq.com>wrote:

> Hi Chris,
>
> 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.
>
> > 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. After a timeout or the response is delivered, the queue is taken
> down. As a result, we have queues come and go a few times a minute... not
> really ideal, but it helps with debugging. Beyond this, I think the rabbit
> setup is pretty standard. Any ideas?
>
> How is the timeout done? Are you using our queue expiry timeout
> extension or some other mechanism? This might require some mnesia
> tuning, but I'm amazed if it does and you're the first person to run
> into this - it's such a common scenario I'm sure we'd have heard about
> it earlier.


I use the rabbit max message lifetime option on some queues, but in general,
the timeout is in the application layer, where if a response isn't received
in a certain amount of time, the application assumes it is lost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110622/2296059e/attachment.htm>


More information about the rabbitmq-discuss mailing list