[rabbitmq-discuss] possible rabbitmq bug
Chris Behrens
cbehrens at codestud.com
Thu Aug 25 17:56:29 BST 2011
Hi,
I've been working with various python modules (carrot, kombu.. all using the python amqplib underneath) and I have spotted what I think may be a bug with rabbit. I'd love to hear if anyone else is run into this or if I'm just plain wrong.
I've been creating code that will re-use rabbit connections (they're pooled) to avoid the unnecessary cost of closing and reopening connections all of the time. I create a channel on which I declare an exchange/queue with auto_delete=True. If I do absolutely nothing more with this channel, and then close the channel, rabbit continues to have an empty queue sitting around _until_ the connection is closed. It seems that closing the channel should nuke the queue, but it doesn't. (This is not a very good use case I realize, but it can happen if I have some error handling in between declaring the queue and consuming it which ends up closing the channel before consuming.)
More of a problem is that this is also the behavior if I consume with methods that result in a basic_get amqp command (NOT a basic_consume command). Ie, if I create a channel, declare a queue auto_delete=True, use _only_ basic_get() to consume the queue and then close the channel when the queue is empty, the queue is also NOT nuked in this scenario. This causes a huge problem when re-using connections that have declared random queue names. Every time a connection is pulled from the pool and used, I have a random queue name lying around... _until_ the connection is closed. Shouldn't closing the channel end up removing the empty queue, as there's no more consumer for it?
NOTE: This problem goes away once you call basic_consume(), instead. Once you've called basic_cancel(), you can basic_cancel() it, and the queue goes away. Alternatively, instead of calling basic_cancel(), I can just close the channel, and the queue will go away. So, the workaround to my problem is to always use basic_consume() instead of basic_get() (which is more efficient, anyway).... BUT I still have this rare corner case described first above. Ie, if I declare an auto_delete queue on a channel, and immediately close the channel... the queue is left around when it should be removed.
The complete workaround is to close the connection to rabbit, but then that means I can't use a pool of connections and recycle them anymore, obviously. I lose the efficiency gained by not having to close/reopen connections all of the time.
Comments?
Thanks,
- Chris
More information about the rabbitmq-discuss
mailing list