Hi Alfonso,<br><br><div class="gmail_quote">On Thu, Feb 10, 2011 at 9:44 AM, Alfonso Pantoja <span dir="ltr"><<a href="mailto:alfonso.pantoja@gmail.com">alfonso.pantoja@gmail.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;">
Can anyone tell me how to deal with queues that contain messages that<br>
are higly recommended by business logic to be ordered?<br>
<br>
As far as I know when messages are not acked and a BasicRecover(true)<br>
is done or the consumer is reconnected all these messages are requeued<br>
so the order is lost.<br>
<br>
The more suitable strategy I've found in queues where ordering is<br>
important is to use one consumer that stops the consuming process<br>
conditioned to the treatment of the message. In other words, it does<br>
not consume any more message until the current message is, for<br>
example, successfully stored in the database.<br>
The drawback of this is that in case of a consumer is disconnected the<br>
current message is not acked so it will be requeued so the order will<br>
be lost.<br>
<br>
<br>
<br>
Advice on this would be really appreciated :)<br>
<br></blockquote><div><br>Whenever I hear about the problem of the required order of messages having to be preserved, I start to wonder if the problem at hand is really best suited to messaging. Could it be that you might be better served by something like a (normal) work queue? <br>
<br>If you require things to be done in a certain order, then you need to have a place to actually keep them in that order. Messaging isn't the place to do this.<br><br>Your scenario sounds like you would like to store your "stuff" in order someplace, have a worker mark it as being worked upon, and remove it only once the worker is finished.<br>
<br>Sorry for not giving much rabbity help,<br>Robby<br><br></div></div>