[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