[rabbitmq-discuss] Ack semantics in RabbitMQ

[Eran Sandler]

Thanks Tony.

This looks like an interesting semantics for this.

Eran

On Tue, Mar 17, 2009 at 1:11 PM, Tony Garnock-Jones <tonyg at lshift.net>wrote:

> Eran Sandler wrote:
> > 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.
>
> Another approach is to set the prefetch window to 1, and start a
> consumer. If you really did only want a single message, you can cancel
> the consumer before acking the message. Otherwise, when you ack it, the
> server will send you the next waiting message if there is one.
>
>  --> BASIC.QOS{ prefetch_count = 1 }
>  --> BASIC.CONSUME
>  <-- BASIC.CONSUME-OK
>  ... wait for a message to arrive ...
>  <-- BASIC.DELIVER
>  --> BASIC.CANCEL
>  <-- BASIC.CANCEL-OK
>  ... processing of message ...
>  --> BASIC.ACK
>
> versus
>
>  --> BASIC.QOS{ prefetch_count = 1 }
>  --> BASIC.CONSUME
>  <-- BASIC.CONSUME-OK
>  ... wait for a message to arrive ...
>  <-- BASIC.DELIVER
>  ... processing of message ...
>  --> BASIC.ACK
>  ... wait for a message to arrive ...
>  <-- BASIC.DELIVER
>  ... processing of message ...
>  --> BASIC.ACK
>  ...
>
> Regards,
>  Tony
> --
>  [][][] Tony Garnock-Jones     | Mob: +44 (0)7905 974 211
>   [][] LShift Ltd             | Tel: +44 (0)20 7729 7060
>  []  [] http://www.lshift.net/ | Email: tonyg at lshift.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20090317/7bc84d40/attachment.htm