[rabbitmq-discuss] adjusting timeout for non-acked messages to be requeued

Wed Jan 6 11:03:08 GMT 2010

Hi Vishnu,

On Wed, Dec 30, 2009 at 09:07:53AM +0530, vishnu wrote:
>    thanks, I think Im getting a better understanding now. Initially I wanted
> to look at auto requeueing for circumstances when my client subscribing to
> events went down or got disconnected. Now my understanding is that in those
> cases, messages get auto requeued.

Correct.

>     However, if I choose not to autoack, then it looks like the
> responsibility of requeuing a client, forcing a time delay on the delivery
> and also maybe forcing a limit on the number of passes through the queue is
> going to have to become subscriber responsibility. I was hoping to handle
> that as a configuration on the queue itself outside of code, but I guess
> that isn't possible.
> 
> (the use case we have requires us to make sure that every message is
> processed as far as possible. Meaning actual failures and successes are sent
> onward, but failures for technical reasons require us to try again later, by
> which time the technical issue might have been resolved).

Rabbit does eventual delivery. Thus eventually, the message will be
delivered. However, it may be delivered to more than one consumer. A
message that is not ack'd will, when the channel on which it was
delivered closes (or the connection, or some other condition that I
always forget, but which Matthias pointed out within about the last
month on this list), be reinserted into its queue to be redelivered.

Thus if you set qos.prefetch to 1, don't auto-ack, and then your client
goes down, you have the following set of properties:
1) Your client will only receive the next message when it's successfully
ack'd the current message.
2) If the client crashes, at most 1 message (i.e. the message that it's
currently processing) will be requeued.
3) If you want to do timeouts, if depends where you wish to put the
timeout - kill clients if they're taking too long (this seems odd) - or
drop messages you receive (i.e. ack them but do no work) if they're
deemed too old. But yes, that's all client-side logic - we don't do TTL
in the server yet.

Matthew