<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'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'm not closing resources properly here), I'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"><<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>></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'm going to craft a vanilla consumer and try it. I *don'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'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>
<<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a> <mailto:<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>><u></u>> 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 "managed consumers that recover from<br>
connection loss and re-attach to the broker". 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>