[rabbitmq-discuss] Ack semantics in RabbitMQ

Sun Mar 15 09:55:31 GMT 2009

Hi Matthias,

Thanks for responding.

There is a couple of projects at work that will require an async system
based on message queues. I don't want to lose anything and I do want to
handle cases in which the message was consumed (and not acked yet) and
something bad happend. In which case, I want to ack a message only when I
know for sure that the actions that this message triggered finished
correctly.

So, the current behavior is well suite for me.

Regarding the blocking "GET" commands, I read about Kesterl (in the link I
gave below) and thought its an interesting approach to make pulling a bit
more efficient instead of sending the "puller" back to a short sleep.

That's basically the only scenario. I don't think its too important. What
was more important to me was understanding the exact Ack semantics (which is
implemented exactly as I want it to be :-) ).

With the new command line tool that allows getting the queue length, I can
easily write a script to let Nagios alert me if the rate of messages going
in is higher than the rate of them coming out.

Eran

On Fri, Mar 13, 2009 at 2:24 PM, Matthias Radestock <matthias at lshift.net>wrote:

> Eran,
>
> Eran Sandler wrote:
>
>> In a consumer pull model, where consumers pull the queue once in a while
>> (without subscription) and you have multiple consumer, if a consumer pulls a
>> message (without auto ack) and doesn't ack it can another consumer still get
>> it or is it marked in a certain way until its acked and deleted?
>>
>
> The AMQP ack model for subscriptions and "pull" are identical. In both
> cases the message is kept on the server but is unavailable to other
> consumers until it either has been ack'ed (and gets removed), nack'ed (with
> basic.reject; though RabbitMQ does not implement that) or the
> channel/connection is closed (at which point the message becomes available
> to other consumers).
>
>  Assuming when a message is pulled and not acked yet and no other consumer
>> can pull it until its either acked or rejected back to the queue, will it
>> have a certain timeout that it was pulled and wasn't acked for X amount of
>> time?
>>
>
> There is no timeout on waiting for acks. Usually that is not a problem
> since the common cases of a missing ack - network or client failure - will
> result in the connection getting dropped (and thus trigger the behaviour
> described above). Still, a timeout could be useful to, say, deal with alive
> but unresponsive consumers. That has come up in discussion before. Is there
> a specific use case you have in mind that requires such functionality?
>
>
> Regards,
>
> Matthias.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090315/5ec0fd37/attachment.htm 