[rabbitmq-discuss] Ack semantics in RabbitMQ

[Eran Sandler]

Hi all,

I'm trying to find a bit more information about the ack semantic in RabbitMQ
in a specific scenario.

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?

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?

The reason I'm asking all of this is that after reading the post from one of
the Twitter engineers on Kesterl (
http://robey.lag.net/2008/11/27/scarling-to-kestrel.html) which is what
replaced Scarling, they added a couple of features I would really like to
see on RabbitMQ (and they might already be there).

The first is the "ack" logic they have on Kesterl (though I would also
prefer to have a timeout until a message is acked).

The blocking calls are interesting, but I think that other features such as
flow control can easily have a better semantics than the blocking pull
calls.

Of course, there is the flow-to-disk feature which a lot of people have
asked (I'm really doing my best to get up to speed on Erlang to see if I can
help ;-) ).

Anyone care to map the feature of Kesterl to RabbitMQ (or even to AMQP) and
mark what is the diff and if its needed or can be replaced by another
feature?

Thanks in advnace,

Eran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090312/53761e5b/attachment.htm