<div dir="ltr">Hi Simon,<div><br></div><div style>We aren't doing anything like that. Whenever one of our services starts (which are based on Kombu, if that helps), it plucks a connection from its internal pool, creates a channel on that connection, then binds on its request queue, which hangs around until the service stops. The only thing that deviates from this pattern is our monitor, which connects and disconnects fairly rapidly, and uses exclusive queues.</div>
<div style><br></div><div style>That said, it's entirely possible that we have something floating around that I don't know about that fits the behavior you described. I'll keep digging and see what I can turn up. In the meantime, let me know if there's any more information I can collect from Rabbit.</div>
<div style><br></div><div style>Thanks, Travis</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 19, 2013 at 6:13 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 18/06/13 16:11, Travis Mehlinger wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We declare those queues as exclusive so they're getting cleaned up<br>
automatically.<br>
</blockquote>
<br></div>
I have found a plausible candidate for the leak. But it's dependent on having a long lived channel which declares and deletes lots of short-lived queues. We keep some information on the deleted queues until the channel is closed. Could your monitoring tool be doing that? Obviously it would have to be deleting queues explicitly, not relying on them being exclusive.<br>
<br>
Cheers, Simon<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, Pivotal<br>
</div></div></blockquote></div><br></div>