Hi Matthias,<div><br></div><div>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.<br>
</div><div><br></div><div>Thanks,</div><div>--Robin</div><div><br><br><div class="gmail_quote">On Sun, Feb 20, 2011 at 6:44 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Robin,<div><br>
<br>
Robin Harvey wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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?<br>
</blockquote>
<br></div>
You could get the client send a basic.cancel and then basic.reject all messages received already and until the basic.cancel-ok arrives.<br>
<br>
However, since you mention "unwanted" messages, why would you cancel the consumer? Wouldn't you just want to reject individual messages but continue consuming?<div><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br>
</blockquote>
<br></div>
basic.cancel does not result in any requeueing of messages. It simply tells the server to stop sending messages to the consumer.<br>
<br>
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.<br>
<br>
However, since the subject of this email mentioned "unwanted" messages, why do you want them requeued at all?<div><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
is there anything I can do to prevent this re-ordering?<br>
</blockquote>
<br></div>
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.<div>
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I suppose that using basic.get instead would probably do the trick<br>
</blockquote>
<br></div>
Requeuing of a message fetched with basic.get behaves no different from that of a message received as a result of a basic.consume.<br>
<br>
Regards,<br><font color="#888888">
<br>
Matthias.<br>
</font></blockquote></div><br></div>