<font face="trebuchet ms,sans-serif">Hi Matt, I&#39;ve gone through the old thread very quickly so forgive me if I&#39;m missing something. Your first sentence leaves me with some doubts:<br></font><br><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div>As I&#39;ve detailed in other posts to this DL (<a href="http://bit.ly/zf6sKC" target="_blank">http://bit.ly/zf6sKC</a>), we have situation where straightforward publisher-confirms aren&#39;t appropriate in our scenario. We need to know the broker has received the message, and we have to assume our client can die at any moment, so retransmitting messages is not an option for us.</div>

</div></blockquote><div><br></div><div><font face="&#39;trebuchet ms&#39;, sans-serif">Publisher confirms guarantee that the broker has taken care of the message and it has been either delivered to a queue or to a consumer. This is a strong delivery guarantee, even if the client dies. Coupled with persistent messages and durable exchange/queues, it guarantees at-least-once delivery. Can you describe why you think publisher confirms are not appropriate in your scenario?</font></div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div></div><div>What I&#39;d like to know is: Is there any benefit to creating our own &quot;blocking publisher-confirm publishing&quot;? That is, we&#39;d do the following:</div>

<div><br></div><div>Publish a single message</div><div>Block on an event &#39;X&#39;</div><div>When the publisher confirm comes in, signal &#39;X&#39;</div><div>Return from the publish call</div></div></blockquote><div><br>

</div><div><font face="&#39;trebuchet ms&#39;, sans-serif">If you happen to be using the .NET API this is already implemented, the WaitForConfirms and WaitForConfirmsOrDie on the IModel interface provide this behavior.</font></div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div>In a mirrored queue scenario, is there any advantage to doing this vs. using straight-up transactions?</div>

<span class="HOEnZb"><font color="#888888"><div><br></div><div>Matt</div></font></span><div><br></div><div>p.s. I realize in the above pseudocode that multiple threads would be necessary - One to block and the other to listen for the publisher-confirm.</div>

<div><br></div></div>
<br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br>