Hello

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.
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?
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?

thanks
pradeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111210/36d9b3aa/attachment.htm>

Search Discussions

  • Emile Joubert at Dec 12, 2011 at 10:43 am
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedDec 10, '11 at 5:33p
activeDec 12, '11 at 10:43a
posts2
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Emile Joubert: 1 post Pradeep w: 1 post

People

Translate

site design / logo © 2022 Grokbase