"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;
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;
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 seeconsumer, 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;
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.
