<div dir="ltr">Ok, to update this list on my findings. The issue is indeed isolated in rabbiteasy, and how it incorrectly manages channels with multiple consuming instances. I'm going to log an issue there, and provide a small sample showing the problem - it only happens when you register multiple listeners. The vanilla version attached early demonstrates that rabbitmq 3.1.3 server and client libraries work as expected. We're ripping out our rabbiteasy dependency and reverting to vanilla API, which is actually easier to understand in our system. <div>
<br></div><div>Sorry for the noise, and thanks Matthias for the quick answers<br><div> </div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 8, 2013 at 3:21 PM, Tim Robertson <span dir="ltr"><<a href="mailto:timrobertson100@gmail.com" target="_blank">timrobertson100@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>[stupidly I replied only to Matthias without noticing]</div><div><div class="h5"><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><div>
<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></div></div>
</blockquote></div><br></div>