<div dir="ltr">I will do some more testing today based on your&#39;s and and Tim&#39;s suggestions.<div><br></div><div style>For the record, the connection/channel never closes.  After processing one message from the queue the consumers go back and look for more.  Once they are idle again I can get all 30 consumers to respond to one message.</div>
<div style><br></div><div style>There is no delay in redelivery either.  The consumers all seem to get the message at the exact same time.</div><div style><br></div><div style>Thanks for your quick responses.  I&#39;ll reply back when I have investigated more.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 16, 2013 at 4:53 AM, Simon MacMullen <span dir="ltr">&lt;<a href="mailto:simon@rabbitmq.com" target="_blank">simon@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"><div class="im">On 16/05/13 08:08, Tim Watson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Once a message is acked and<br>
delivered, a queue will not send it (i.e., the same message) to any<br>
further consumers.<br>
</blockquote>
<br></div>
This is the key point. It will also not redeliver it if the consumer just acks slowly.<br>
<br>
But the fact that turning off acks solves the problem suggests that the messages *are* getting redelivered - so the OP should check the consumer code and make sure that messages are being acked before the connection or channel is closed.<br>

<br>
Cheers, Simon<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, Pivotal<br>
</font></span></blockquote></div><br></div>