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

David Wragg
Staff Engineer, RabbitMQ
VMware, Inc.

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 3 | next ›
Discussion Overview
grouprabbitmq-discuss @
postedJun 2, '11 at 12:43p
activeJun 2, '11 at 2:28p



site design / logo © 2022 Grokbase