<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 22, 2014 at 9:07 AM, Bertrand LEMASLE <span dir="ltr"><<a href="mailto:blemasle@allocine.fr" target="_blank">blemasle@allocine.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br></div></div><div>After reading many docs and mails on this subject (<a href="http://www.rabbitmq.com/confirms.html" target="_blank">http://www.rabbitmq.com/confirms.html</a> included which explains when a message will be confirmed), I still haven't found an answer to my question. When using publisher confirm (by using confirmSelect on the channel), messages aren't ack until they are either ack or nack by at least one consumer.</div>
</div></blockquote><div><br></div><div>Totally unrelated.  The publisher confirm mechanism only goes so far as the transfer of responsibility for a message's well being from the *publisher* into the *broker*. </div><div>
<br></div><div>Receipt of a publisher confirm means the broker has accepted your message and done what you asked of it, e.g. persisted it to disk, made sure it was replicated to any applicable mirrored queues, etc.</div><div>
<br></div><div>Consumers consume from queues, and their AMQP Ack mechanism is analogous to, in the sense of responsibility transfer, but *totally uncoupled from* any publisher confirm happening on the inbound side.</div><div>
<br></div><div>If you really need round trip acknowledgment from producer -> broker -> consumer -> back to producer, you need to build that into your messaging workflow as, for example, our simple RPC over AMQP facility does.  You might look at the tutorial examples using it, since they may directly fit your intended use case.</div>
<div><br></div><div>Best regards,</div><div>Jerry</div><div><br></div></div></div></div>