openstack team mailing list archive

[Mark McLoughlin <markmc@xxxxxxxxxx>]

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.