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

[Juan Wajnerman]

On Apr 2, 2010, at 1:54 PM, Matthew Sackman wrote:

> Actually, I think you'll see this bug if you just do: subscribe,
> unsubscribe, recover. The second subscription should be unnecessary.

Yes, you're right. 



> 
> Yes. There's probably an argument for saying that in the absence of a
> valid consumer tag, the messages should be sent to the client as a
> sequence of basic.get-oks, or at least a basic.deliver with a very
> special ctag to indicate to the clients that they shouldn't be suprised
> by these deliveries which are apparently appearing outside of the scope
> of any subscription it knows about. This really seems to be a bug in the
> spec rather than our implementation or the client.
> 
> At the very least, the basic.recover_ok should contain a new ctag (which
> for symmetry suggests the client should be able to specify one in
> basic.recover to mirror basic.consume and basic.consume_ok) which the
> client can then use to identify these deliveries and route them
> accordingly.

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.
Why don't just redeliver the messages to other possible subscribers after the subscription
cancel was received? 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?

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.

> I would recommend that you don't use recover without also setting
> requeue=true, thus ensuring the messages are inserted back into the
> queue and can hence be redelivered to any valid consumer again (at
> which point the ctag will be set correctly). Hopefully you'll at
> least get unsurprising behaviour! I will raise some bugs to cover the
> issues uncovered - many thanks for the report.

Yes! this solved my issue.

- Juan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100402/afe1c7a5/attachment.htm