I also thought we acked then processed messages in the applications (nova, cinder...),
This means the applications can crash, and the message can then be lost (and in the cast case, the message is gone, in the call case hopefully the caller times out, although if the caller also crashes, all bets are off...) Instead of process then ack (and ensure that things are idempotent if a redelivery is triggered). IMHO I'd rather fix the idempotent and state problem, and deal with redelivery, although I think there are historical decision at work here that decided against this (?). Each way though has its own set of tradeoffs, so it really starts to become an application decision (aka oslo.messaging is not at the right level to determine this). -----Original Message----- From: Gordon Sim <g...@redhat.com> Organization: Red Hat UK Ltd, Registered in England and Wales under Company Registration No. 3798903, Directors: Michael Cunningham (USA), Matt Parsons (USA), Charlie Peters (USA), Michael O'Neill (Ireland) Date: Thursday, October 16, 2014 at 6:26 AM To: Aaron Knister <aaron.knis...@gmail.com> Cc: "openstack@lists.openstack.org" <openstack@lists.openstack.org> Subject: Re: [Openstack] Messaging reliability/durability expectations >On 10/16/2014 01:51 PM, Aaron Knister wrote: >> Thanks, again, for your replies. I started looking at the code to see >> about implementing acknowledgements in the Qpid driver and I'll admit >> after some digging I've come up confused. These lines (it's in master >> as well as the stable icehouce branch) http://git.io/w3KkQw and >> http://git.io/SiO5cg suggest that acknowledgements *are* sent by the >> qpid driver when messages are consumed. Am I making too broad an >> assumption here? > >The acknowledge() call is made, but at the protocol (i.e. AMQP 0-10) >level this is only relevant if the message was delivered with an >'accept-mode' of 'explicit'. The broker will determine the accept-mode >to use based on that requested in the message-subscribe command sent by >the client. With the qpid.messaging API, this is controlled through the >'reliability' option in the link options within the address. For >addresses based on an exchange, the default is to use an auto-deleted >subscription queue with accept-mode 'none' (if the queue is autodeleted, >there is no benefit to acknowledgements anyway, since the queue and its >messages are lost if the subscribing connection is lost). > >_______________________________________________ >Mailing list: >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >Post to : openstack@lists.openstack.org >Unsubscribe : >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
