[rabbitmq-discuss] Treating the Ack Message

Thu Jun 2 14:53:58 BST 2011

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