[rabbitmq-discuss] Message redelivering doubt with one and with more than one consumers.
alfonso.pantoja at gmail.com
Thu Feb 10 09:26:53 GMT 2011
on the RabbitMQ FAQ page I see the response to
"Can you explain the cases where a message might be delivered to a
consumer more than once?"
"If a message is delivered to a consumer, and that consumer then dies
(or closes the channel which has the subscription to the queue, or
closes the connection itself) without acking the message, then
RabbitMQ will reinject the message into the queue. If that same
consumer then reconnects and creates a new subscription to the same
queue, it's possible it'll receive the same message again. This is 'at
least once' delivery and is very deliberate design to ensure that
messages are not lost in transit."
So my doubt is:
In a scenario with one consumer as I saw in my tests, the consumer
received messages with the Redelivered=true AMQP header atribute.
The consumer was based in the classes provided by the .NET API and as
I remember the consumer-tag is random generated by the server.
When there is a only one consumer (with a random consumer-tag name)
and a message is not acked when the consumer is reconnected (so has
another random tag name) that message is redelivered?
Based on my experience I think this is true but don't understand that
"If that same consumer then reconnects and creates a new subscription
to the same queue"...
By the was my consumer always tries to create the queue and the
bindings every time it connects to RabbitMQ.
And also I'm wondering how this behavior acts when there are more than
one consumer (same queue and same bindings)...
Under what circumstances an unack message wouldn't be redelivered again?
Thank you in advance.
The consumer can also call basic.recover which tells rabbit to resend
all the messages sent to the consumer for which rabbit has not
received an ack for. This basically amounts to the consumer saying "I
know you sent me some messages, but I've forgotten what they are.
Could you resend them all again?".
More information about the rabbitmq-discuss