[rabbitmq-discuss] Old consumer tags delivered after re-subscribing to a queue

[Matthew Sackman]

On Thu, Apr 01, 2010 at 12:05:25PM -0300, Juan Wajnerman wrote:
> After unsubscribing from a queue, following "recover" calls will still redeliver unack'd messages through the channel. Even worse, after resubscribing to the queue, the recovered messages are still sent with the old consumer tag.

The documentation of basic.recover is clear:
"This method asks the server to redeliver all unacknowledged messages
on a specified channel."

I don't know the ruby library at all, but I assume from your code below
they inverted the noAck flag to ack, hence your :ack => true indicates
you are commiting to acking messages manually. Your code does not do that
hence every message you receive as part of the subscription is unack'd,
hence will be redelivered when you issue the recover.

Similarly, the documention for basic.cancel (unsubscribe):
"This method cancels a consumer. This does not affect already delivered
messages, but it does mean the server will not send any more messages for
that consumer."

Thus it is clear that cancelling your subscription does not void your
commitment to acknowledge the messages you've already been sent.

> I'm using the amqp ruby library to consume the queues. Here's a small snippet that reproduces the issue. When I execute this, I always get an error similar to: Basic.Deliver for invalid consumer tag: myqueue-396735623077.

That really shouldn't be happening - and I suspect it's a client bug.
I've just checked our code - the queue is told to forget about the
consumer tag on the basic.cancel, and is told about the new consumer
tag on basic.consume. Your ctag of myqueue-396735623077 is clearly one
that you, or the library, is specifying - all the server generated
ctags start "amq.ctag-". I have no idea what the ruby amqp library is
doing under the bonnet - given that you're not supplying a ctag
yourself, nor should the library.

Matthew