Matthias, thanks for the explanation.  Considering your points below, I now have a better understanding on your thought that the actual use-cases and practicality to publish messages with the immediate flag are minimal.  In light of the details, I won&#39;t be using it -- faster mirrored queues sounds better to me.  :o)<div>
<br></div><div>-Randall<br><br><div class="gmail_quote">On Fri, Sep 14, 2012 at 8:48 AM, Matthias Radestock <span dir="ltr">&lt;<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Richard,<div class="im"><br>
<br>
On 14/09/12 13:34, Randall Richard wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Admittedly, I&#39;m not fully aware of exactly how it works.  It would be<br>
helpful to have a better understanding of the semantics.  Can you<br>
explain what the publisher is notified of (if anything?) when there are<br>
10 queues bound to an exchange named HighPriority, a message with<br>
immediate flag true is published to HighPriority, and 7 out of the 10<br>
queues have the message consumed immediately.<br>
</blockquote>
<br></div>
No notification is sent to the publisher in that case. A basic.return is only sent if *no* queues were able to send the message to a consumer immediately.<br>
<br>
Here are a few more warts about &#39;immediate&#39;:<br>
<br>
- while a message might get sent out to a consumer straight away, there is of course no guarantee that such a message will reach the consumer, get processed and ack&#39;ed. If any of these steps go wrong the message will end up in the queue (unless the consuming happened with no-ack, in which case it is simply lost), even though supposedly it was delivered immediately.<br>

<br>
- a queue can have a consumer and yet &#39;immediate&#39; delivery may fail (and a basic.return issued) because:<br>
a) the consumer isn&#39;t quick enough and a backlog of messages has built up,<br>
b) the consumer has configured a &#39;basic.qos&#39; prefetch count and that the limit has been reached<br>
<br>
- the interaction with transactions is not at all obvious. This does apply to &#39;mandatory&#39; too though. See <a href="http://www.rabbitmq.com/semantics.html#tx" target="_blank">http://www.rabbitmq.com/<u></u>semantics.html#tx</a><br>

<br>
Regards,<br>
<br>
Matthias.<br>
</blockquote></div><br></div>