[rabbitmq-discuss] AutoAck issue

[Adam Morgan]

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:

Hi Adam,

On 30 May 2013, at 13:38, Adam Morgan wrote:

AutoAck issue
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.

Cheers,
Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130530/e923af7a/attachment.htm>