[rabbitmq-discuss] AutoAck issue
AMorgan at salesforce.com
Thu May 30 14:12:08 BST 2013
Ok thanks for the clarification Tim, Simon, and Emile... Yes, I was definitely mixing acks and confirms. So in effect, everything is working properly! Ha! :)
So the consumer acks are to tell the broker that the message has been dealt with, and doesn't need to be consumed again. Of course!
On 5/30/13 9:57 AM, "Tim Watson" <tim at rabbitmq.com> wrote:
On 30 May 2013, at 13:38, Adam Morgan wrote:
I am trying to implement guaranteed delivery in my system but am having issues around acknowledgements being sent automagically.
* I have turned on channel.confirmSelect() on publishing channel.
* I have added my publisher as a ConfirmListener to the publishing channel.
* I very clearly have autoAck=false in my basicConsume() call.
Despite this, my publisher/ConfirmListener is receiving an ack as soon as my consumer receives the message. Repeat, my consumer client has NOT yet called basicAck(), but my publisher/ConfirmListener callback is made.
Is there something else I should be doing? Is there other configuration I might be doing that would interfere with this?
I think you're getting confused between confirms and ACKs. Confirms sent from the broker to a producer are orthogonal to ACKs sent from a consumer to the broker. When the broker has accepted responsibility for a message, it will send a confirm _in the form of an ACK_ to the publisher. Now "accepted responsibility" means various things depending on you configuration - see https://www.rabbitmq.com/reliability.html for details - but in general, if the broker is able to immediately deliver a message to an active consumer, then it has certainly discharged it's responsibility "to the producer" for handling that message, therefore it sends a confirm (i.e., an ACK) to the producer. This is completely independent of what the consumer does with the message - it might NACK/REJECT it but that's "the broker's problem to handle" and not the producer's. Once the broker sends a confirm, *it* is responsible for the message.
What you appear to be looking for is a kind of RPC (in terms of synchronicity) between producer and consumer, and /that/ is not what messaging systems typically deliver, opting instead for a de-coupled view of the interaction via an intermediary (i.e., the broker). Notably, even JMS transactions do *not* coordinate over both the producer and consumer, but handle only one perspective or the other.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss