[rabbitmq-discuss] What to do with "unwanted messages"
matthias at rabbitmq.com
Sun Feb 20 18:44:06 GMT 2011
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
> 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.
More information about the rabbitmq-discuss