<HTML>
<HEAD>
<TITLE>Re: [rabbitmq-discuss] AutoAck issue</TITLE>
</HEAD>
<BODY>
<FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>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! :)<BR>
<BR>
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! <BR>
<BR>
<BR>
On 5/30/13 9:57 AM, "Tim Watson" <<a href="tim@rabbitmq.com">tim@rabbitmq.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>Hi Adam,<BR>
<BR>
On 30 May 2013, at 13:38, Adam Morgan wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>AutoAck issue <BR>
I am trying to implement guaranteed delivery in my system but am having issues around acknowledgements being sent automagically.<BR>
<BR>
</SPAN></FONT><UL><LI><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>I have turned on channel.confirmSelect() on publishing channel.
</SPAN></FONT><LI><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>I have added my publisher as a ConfirmListener to the publishing channel.
</SPAN></FONT><LI><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'>I very clearly have autoAck=false in my basicConsume() call.<BR>
</SPAN></FONT></UL><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'><BR>
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. <BR>
<BR>
Is there something else I should be doing? Is there other configuration I might be doing that would interfere with this? <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Lucida Grande"><SPAN STYLE='font-size:11pt'><BR>
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 <a href="https://www.rabbitmq.com/reliability.html">https://www.rabbitmq.com/reliability.html</a> 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.<BR>
<BR>
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.<BR>
<BR>
Cheers,<BR>
Tim<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>