Open Stack

On Thu, May 31, 2012, Mark Washenberger <mark.washenberger at rackspace.com> wrote:
>  * not be tied up with eventlet on the consumer side

Yes!

>  * let the consumer code decide when to ack a message
>    (although maybe the concept of acking doesn't exist for all implementations?)

My XenAPI idempotency branch delays ACKs until after it's done processing
the message to ensure we get the message again after restart.

https://review.openstack.org/#/c/7323

I can't say that I'm happy with the changes I've made to safely support
delayed ACKs.

As far as implementations go, the Qpid docs say messages should be
acknowledged, but I don't see anywhere in the code where that happens.
I haven't dug too far into it to figure out this discrepancy.

While the 0MQ code hasn't been merged yet, 0MQ appears to have no concept
of acknowledging messages.

Between the messy code in supporting delayed ACKs and the fact that some
RPC implementations don't appear to support ACKs at all, it may mean
reliability will need to be implemented elsewhere.

The proposed orchestration work could possibly work as an alternative.

JE