<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Adam,<div><br><div><div>On 30 May 2013, at 13:38, Adam Morgan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<title>AutoAck issue</title>
<div>
<font face="Lucida Grande"><span style="font-size:11pt">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><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><li><font face="Lucida Grande"><span style="font-size:11pt">I very clearly have autoAck=false in my basicConsume() call.<br>
</span></font></li></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></div></blockquote></div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Tim</div></body></html>