Hi,



I am new to RabbitMQ and I am starting with test and prototypes. I have
pretty basic questions:



1) When the client sends a message to a service and the server
crashes before it can send back the ack to the client the message stays
in the queue.

How can the client know the message has not been received, by a timeout
???

2) In this case when the server runs again I would like to clear
all the messages not received.



What could be the best practice to treat this problems.



Thanks in advance.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110602/6f97480c/attachment.htm>

Search Discussions

  • David Wragg at Jun 2, 2011 at 1:53 pm

    "Marcus Vinitius Baffa" <mbaffa at opus.com.br> writes:
    I am new to RabbitMQ and I am starting with test and prototypes. I have
    pretty basic questions:

    1) When the client sends a message to a service and the server
    crashes before it can send back the ack to the client the message stays
    in the queue.

    How can the client know the message has not been received, by a timeout
    ???
    I'll use the terms "producer" and "consumer", rather than "client" and
    "server", because the latter terms risk confusion: All agents sending
    and receiving messages are clients of rabbitmq-server (the broker).

    There are a couple of AMQP features related to your question. On a
    publish operation, you can set the "mandatory" and "immediate" flags.
    "mandatory" tells the broker that the producer expects the message to be
    directly routed into at least one queue (rather than being dropped
    because there were no bindings of the exchange that matched the
    message). "immediate" says that the producer expects the message to be
    directory routed to a consumer via a queue immediately. If these flags
    can't be satisfied, the error is signalled to the producer.

    But neither of these give you what you ask for: "mandatory" merely says
    that the message should be routed to a queue, and says nothing about
    receipt by a consumer. "immediate" really does require immediate
    delivery to a consumer. If the consumer is already processing earlier
    messages, so that the message cannot be delivery due to outstanding
    acknowledgements, the publish will fail.

    So if you want to send a message from a producer to a consumer, and have
    the consumer know whether the message was processed by a consumer within
    a certain time, then you will need to make the consumer send a response
    message back to the original producer in your application's code.
    2) In this case when the server runs again I would like to clear
    all the messages not received.
    There is a purge operation that clears a queue. So your consumer should
    purge its queues on startup.

    But note that what you are asking for will tightly couple your clients
    and servers. One of the benefits of using a message broker, compared to
    (for example) using HTTP for clients to send requests to servers, is
    that the broker can reliably convey a message even if producers and
    consumers are not running at the same time, or get restarted.

    So for instance, a producer might send a message while the consumer is
    temporarily stopped. When the consumer becomes available again, it can
    start handling the messages sent while it was away.

    Taking advantage of that kind of approach can help to build more robust
    systems.

    --
    David Wragg
    Staff Engineer, RabbitMQ
    VMware, Inc.
  • David Wragg at Jun 2, 2011 at 2:28 pm

    "Marcus Vinitius Baffa" <mbaffa at opus.com.br> writes:
    1) If I understood well the consumer will send an explicit response to
    the producer confirming the service messages was received. The producer
    will wait for this messages and define a timeout to receive this kind of
    customized acknowledge message;
    Right. In an RPC setting, clients can simply timeout if they don't get
    a reply soon enough.
    2) As these messages are RPC messages there is no point for the
    consumer, after a crash, to process messages that possibly had timedout
    so I could simply purge these messages, and additionally send to the
    producer, for each message still in the queue and not processed, a
    special notification message indicating the consumer had crashed. This
    could make the producer, if it is still running, reset the process and
    notify the user what happened;
    3) The producer will allways purge its output queue when it begins to
    run;
    The problem with purging the queue is the your consumer would not see
    requests even if they were sent just before the purge. So it's probably
    better to use RabbitMQ's per-queue message TTL feature. This allows you
    to request that messages by expired from a queue after a certain time,
    and you could configure this to match your timeout period. See
    <http://www.rabbitmq.com/extensions.html#queue-ttl>.

    --
    David Wragg
    Staff Engineer, RabbitMQ
    VMware, Inc.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedJun 2, '11 at 12:43p
activeJun 2, '11 at 2:28p
posts3
users2
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2022 Grokbase