<div class="gmail_quote">On Wed, Jun 22, 2011 at 6:25 AM, Matthew Sackman <span dir="ltr"><<a href="mailto:matthew@rabbitmq.com">matthew@rabbitmq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Chris,<br>
<div class="im"><br>
On Tue, Jun 21, 2011 at 11:18:36AM -0400, Chris Madden wrote:<br>
> I upgraded our erlang version to R14B03, but the LATEST.LOG still continues to be growing, albeit, more slowly perhaps?<br>
<br>
</div>Curious.<br>
<div class="im"><br>
> 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?<br>
<br>
</div>How is the timeout done? Are you using our queue expiry timeout<br>
extension or some other mechanism? This might require some mnesia<br>
tuning, but I'm amazed if it does and you're the first person to run<br>
into this - it's such a common scenario I'm sure we'd have heard about<br>
it earlier.</blockquote><div><br></div><div>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</div>
</div>