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

Fri Apr 2 20:46:59 BST 2010

On Fri, Apr 02, 2010 at 03:01:37PM -0300, Juan Wajnerman wrote:
> At this point I should go and read the full specs to try to understand the reasons for this
> design. However, I don't see the reason for redelivering messages to a consumer that
> already said explicitly that it doesn't want to receive messages from that queue anymore.

Well, the consumer also said "send me messages, and I'll ack them when
I'm done with them". If you don't want them any more, use recover with
requeue=true (which you now have done). It's also possible that you
should be setting qos to some lowish value - between 1 and 10 which will
limit the number of messages that get buffered in the client - i.e. it
should result in fewer messages arriving at the client between you sending
off the cancel and getting the cancel_ok back (in fact, if you're acking
explicitly then it would mean you can't ever receive more messages per
consumer than you have qos set to).

> Why don't just redeliver the messages to other possible subscribers after the subscription
> cancel was received?

Because you might want to say "consume, then I'm going to take the next
N messages, stop consuming, but I'm still going to process those N
messages in my leisure and I'll ack them in due course - but whilst I'm
processing those, I don't want to be receiving any further messages".

> Ok, maybe the consumer can subscribe again using the same ctag (the library
> should allow to do so) or the server should understand the change of ctag, given that there
> cannot be two consumers for the same queue on the same channel, right?

Not with the same ctag. There are all sorts of complications due to the
provision for user-supplied ctags. I wish all ctags were only supplied
by the server, but that's another issue really.

> I just have a couple of weeks of experience with AMQP and RabbitMQ and I'm still
> trying to figure out the architecture patters that I should follow for our design. One thing
> that still results strange to me is that the recover operates only at a channel level and there
> is no way to recover messages just for one queue.

Well that's because recover operates at the channel level, not the queue
level, and that's a design. Really, not many people use recover and not
just because of the reasons you've come across. Also, I would generally
advise that you create new channels for each subscription to a queue you
make - it's not necessary, by any means, but it does keep things like
this a little simpler.

I'm glad the recover with requeue=true worked for you.

Matthew