| Author |
Message |
|
| Guest |
 Posted: Thu Nov 05, 2009 9:58 pm |
 |
|
|
Guest
|
Hello,
I'm having some difficulty with queues not going away even after their
last consumer has gone. The orphaned queues stick around and fill up
with messages until the RabbitMQ server has to be restarted or the
queues manually deleted.
For example, `rabbitmqctl name messages consumers` shows lots of entries
like:
notify.a388d3c7-c501-4fef-92bb-516710950f4a 7198 0
(With the 'messages' column quickly growing in size...)
These queues were created with durable=True, exclusive=True, and
auto_delete=True. It had been my understanding that the last option
bit, auto_delete, would ensure that the queue would be deleted once
there were no more consumers, but that doesn't appear to actually be the
case.
Help?
Thanks,
Tim
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Nov 05, 2009 11:03 pm |
|
|
|
Guest
|
Tim,
Tim Cole wrote:
> I'm having some difficulty with queues not going away even after their
> last consumer has gone. The orphaned queues stick around and fill up
> with messages until the RabbitMQ server has to be restarted or the
> queues manually deleted.
>
> For example, `rabbitmqctl name messages consumers` shows lots of entries
> like:
>
> notify.a388d3c7-c501-4fef-92bb-516710950f4a 7198 0
>
> (With the 'messages' column quickly growing in size...)
>
> These queues were created with durable=True, exclusive=True, and
> auto_delete=True. It had been my understanding that the last option
> bit, auto_delete, would ensure that the queue would be deleted once
> there were no more consumers, but that doesn't appear to actually be the
> case.
Marking an exclusive queue as durable is quite a strange thing to do,
since 'exclusive' means the queue should go away when the creating
connection dies, such as during a broker restart, but 'durable' means it
should survive broker restarts.
There is in fact a known problem with durable, exclusive queues - if the
server restarts it is possible that these queues survive even though
their owning connections are dead.
So I suggest dropping the 'durable' flag.
Also note that auto_delete only kicks in only after the queue has had at
least one consumer registered with basic.consume. basic.get doesn't count.
And exclusivity is attached to the *connection*, not the channel, so
it's worth checking that the connection(s) which created the queues are
indeed dead.
Regards,
Matthias.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Nov 06, 2009 3:45 pm |
|
|
|
Guest
|
On Thu, 2009-11-05 at 23:02 +0000, Matthias Radestock wrote:
> Marking an exclusive queue as durable is quite a strange thing to do,
> since 'exclusive' means the queue should go away when the creating
> connection dies, such as during a broker restart, but 'durable' means it
> should survive broker restarts.
The reason for durable in this case was to match the exchange, since a
decision had been made to declare the exchange manually as a once-off
and keep it around rather than having clients do that. I'm content to
have the clients attempt to declare the exchange if it doesn't exist
though.
> There is in fact a known problem with durable, exclusive queues - if the
> server restarts it is possible that these queues survive even though
> their owning connections are dead.
Hm, in this case the server wasn't restarted, but the clients were shut
down and replaced by new machines. Perhaps it's also an issue if the
connection wasn't shut down cleanly?
> So I suggest dropping the 'durable' flag.
>
> Also note that auto_delete only kicks in only after the queue has had at
> least one consumer registered with basic.consume. basic.get doesn't count.
basic.consume was in use in this case.
> And exclusivity is attached to the *connection*, not the channel, so
> it's worth checking that the connection(s) which created the queues are
> indeed dead.
They definitely are; the client machines to which those queues belonged
were taken down.
Anyway, it sounds like what we want in this particular case is
durable=False, exclusive=True, and auto_delete=False. Ideally, we don't
actually want the queue to go away when the channel/consumer dies, but
only if the connection does. Does that sound right?
Thanks,
-Tim
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Nov 06, 2009 5:01 pm |
|
|
|
Guest
|
Tim,
Tim Cole wrote:
> The server wasn't restarted, but the clients were shut down and
> replaced by new machines. Perhaps it's also an issue if the
> connection wasn't shut down cleanly?
An "abrupt" termination of a client connection will cause the associated
exclusive queues to be deleted. There are no known problems with that
functionality, and it is used widely.
So if the queues stayed around then either they weren't declared as
'exclusive' after all, or the server thought the connections were still
alive.
> Anyway, it sounds like what we want in this particular case is
> durable=False, exclusive=True, and auto_delete=False. Ideally, we don't
> actually want the queue to go away when the channel/consumer dies, but
> only if the connection does. Does that sound right?
Spot on.
Regards,
Matthias.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
