[rabbitmq-discuss] redelivering message without loosing order

[Emile Joubert]

Hi Pradeep,

On 10/12/11 17:33, pradeep w wrote:
>  With the the basic queue based message consumption, I've this scenario
> , where my queue consumer reads message from queue and pass on as
> response to remote application client. However as I may not get the
> message processing response from client immediately, I'll not like to
> acknowledge message while consuming from queue. In the event some issue
> occurs at the application client and I need to resend the earlier
> message, how can i do it.

If the order of messages must be maintained then requeue the message.
See http://www.rabbitmq.com/semantics.html#ordering for applicable methods.

If order is not important then you could simply republish the message.

> In my scenario I also need to take care that the message being
> re-requested should follow the order. And I'm not sure whether
> basicRecover() is the right way as I feel that it may put the content as
> the last entry in queue?

basicRecover() is suitable if you need to return all unacknowledged
messages. Queues maintain publication order of requeued messages from
RabbitMQ v2.7.0. If you use an older version than v2.7.0 then
basicRecover() causes messages to be requeued at the back of the queue.

> For eg: In my case  first message send content which needs to be created
> and the second one is update on the first message's content. For some
> reason first message processing fails and client is not able to give
> reject/acknowldege, the second one may not be requested at all. And when
> the application client next connects it will get the second message
> which will fail due to business logic [as first one is not available].
> I was thinking if it is possible to send the first message again when
> the client reconnects before giving the second message. Is it possible?
> Else what is the alternative?

This sounds like a pipeline where processing involves taking a message
off one queue, doing something to it and then publishing it to another
queue. It depends on your application what should happen if processing
fails at any point. Should the whole pipeline stop or can the processing
of other messages proceed?


-Emile