<div dir="ltr"><div>[stupidly I replied only to Matthias without noticing]</div><div><br></div>Ok - attached a really quick hack which I believe shows 3.1.3 to behave as expected with 1 production thread, and 10 consuming threads. �This is a durable exchange and queue, and it is using explicit ack&#39;ing. �It uses 1 connection for publishing, and 1 connection for all the consuming threads. �Each consuming thread gets a channel.<br>
<div class="gmail_quote"><div dir="ltr"><div>
<br></div><div>If someone familiar with the Java API could cast an eye over that and confirm that it is give or take the expected usage (I&#39;m not closing resources properly here), I&#39;ll then try and work out why I see rabbiteasy does not operate the same.</div>

<div><br></div><div>Curiously, when I ran the rabbiteasy version through Tracer I got the following:�<a href="http://pastebin.aquilenet.fr/?a91d27418ddaade5#8e6MBLhOR+ISSPEtg2QoR0iqURsGgBjBfCbH2dTaj9o=" target="_blank">http://pastebin.aquilenet.fr/?a91d27418ddaade5#8e6MBLhOR+ISSPEtg2QoR0iqURsGgBjBfCbH2dTaj9o=</a></div>

<div>I figured I was using Tracer wrongly, but perhaps that is correct and rabbiteasy does indeed do a reconnect and then does not recover connections properly. �Still more to follow.</div></div><div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br>
<br><div class="gmail_quote">On Thu, Aug 8, 2013 at 3:14 PM, 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">

Tim, please keep the list in the loop on your investigation.<div><br>
<br>
On 08/08/13 13:44, Tim Robertson wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Thanks Matthias,<br>
<br>
I&#39;m going to craft a vanilla consumer and try it. �I *don&#39;t think* this<br>
is related to the connection retrying, as this happens consistently and<br>
immediately when there is more than 1 thread registered with a channel.<br>
� The first consumer ACKs, but I *think* rabbit redelivers it anyway -<br>
more to follow on that.<br>
<br>
I only just started investigations, and came across this thread<br>
immediately. �It is curious we&#39;re both using totally different libraries<br>
(spring, rabbiteasy) and seeing the same behavior though.<br>
<br>
<br>
<br>
<br>
<br>
<br>
On Thu, Aug 8, 2013 at 12:47 PM, Matthias Radestock<br></div><div>
&lt;<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a> &lt;mailto:<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>&gt;<u></u>&gt; wrote:<br>
<br>
� � Tim,<br>
<br>
<br>
� � On 08/08/13 11:39, Tim Robertson wrote:<br>
<br>
� � � � Were there any further insights into this?<br>
� � � � I am seeing the same behavior on 3.1.3 on my mac (homebrew<br>
� � � � install) and<br>
� � � � using rabbiteasy (1.2.0) and amqp java libraries 3.1.3.<br>
<br>
<br>
� � rabbiteasy claims to provide &quot;managed consumers that recover from<br>
� � connection loss and re-attach to the broker&quot;. I strongly suspect<br>
� � that recovery logic is too naive, allowing acks for messages to be<br>
� � span channel recreation, which would result exactly in the error you<br>
� � are seeing.<br>
<br>
� � Regards,<br>
<br>
� � Matthias.<br>
<br>
<br>
</div></blockquote>
<br>
</blockquote></div><br></div>
</div></div></div><br></div>