On Thu, May 31, 2012, Mark McLoughlin <mar...@redhat.com> wrote: > On Thu, 2012-05-31 at 08:58 -0700, Johannes Erdfelt wrote: > > 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.
My only concern with this is that it pushes durability of the message down a layer (assuming no orchestration). It's probably unavoidable to maintain flexibility in the RPC layer, but it does make things more complicated. 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