On Thu, 2012-05-31 at 08:58 -0700, Johannes Erdfelt wrote: > > * 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.
Starting an instance is a long running operation. We confirm its completion by updating the instance state in the DB. We could switch to casting "instance state change" messages instead. Point is, I'd see an ack as "message received, I've acted on it" and handle the completion notification of long running messages separately. Or put it another way, an ack for a long running operation is similar to "202 Accepted" in a REST API. Cheers, Mark. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp