[rabbitmq-discuss] What to do with "unwanted messages"

[Matthias Radestock]

Robin,

Robin Harvey wrote:
> What is the recommended course of action for dealing with unwanted 
> messages in consumers?  If a consumer sends basic.cancel there's a 
> possibility that there will be one or more "undelivered" messages 
> (depending on the prefetch-count parameters), is it best to basic.reject 
> these before or after sending basic.cancel?

You could get the client send a basic.cancel and then basic.reject all 
messages received already and until the basic.cancel-ok arrives.

However, since you mention "unwanted" messages, why would you cancel the 
consumer? Wouldn't you just want to reject individual messages but 
continue consuming?

> A connected issue here is that sending basic.cancel alters the sequence 
> of messages on the target queue, the undelivered message gets requeued 
> at the end of the queue.

basic.cancel does not result in any requeueing of messages. It simply 
tells the server to stop sending messages to the consumer.

However, basic.reject, recover, and nack, and channel/connection 
termination do all cause requeuing. And yes, those messages go to the 
back of the queue.

However, since the subject of this email mentioned "unwanted" messages, 
why do you want them requeued at all?

> is there anything I can do to prevent this re-ordering?

No. In theory rabbit could preserve the order when requeuing and there 
is just a single consumer. But a) that would be going beyond the 
guarantees provided by the AMQP spec, and b) as soon as there is more 
than one consumer there is no sensible way to preserve the order.

> I suppose that using basic.get instead would probably 
> do the trick

Requeuing of a message fetched with basic.get behaves no different from 
that of a message received as a result of a basic.consume.

Regards,

Matthias.