Hi Matthias,<div><br></div><div>yes, I finally decided to handle the reordering in the consumer. Anyway, thank you for the�'redelivered' flag hint, it could be very helpful.</div><div><br></div><div>Best,</div><div>
<br></div><div>Davide</div><div><br><br><div class="gmail_quote">On Tue, Oct 26, 2010 at 4:35 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com">matthias@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Davide,<div class="im"><br>
<br>
Davide Maestroni wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My problem here is that, in the architecture I have to implement, I could receive a lot of messages in a very short time, so if the broker re-enqueues not acknowledged ones they can end up to be re-sent thousands of messages later. Which means that there's no way I can do the re-ordering on the consumer side.<br>
</blockquote>
<br></div>
Could you recover ordering by the producer sticking a sequence number into the message? That should work as long as all the produced messages end up in the same queue.<br>
<br>
Also note that rabbit sets the 'redelivered' flag on deliveries that have been sent to a consumer for the second and subsequent times. This too helps in recovering order.<br>
<br>
<br>
Regards,<br><font color="#888888">
<br>
Matthias.<br>
</font></blockquote></div><br></div>