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

Tue Feb 22 13:26:03 GMT 2011

Hi Matthias,

Thanks for you help, that's cleared a few things up for me.  I had
mistakenly assumed that sending basic.cancel meant you couldn't ack or
reject messages after sending the cancel.

Thanks,
--Robin

On Sun, Feb 20, 2011 at 6:44 PM, Matthias Radestock
<matthias at rabbitmq.com>wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110222/e7c829a4/attachment.htm>