On Thu, May 31, 2012, Mark Washenberger <mark.washenber...@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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
