[rabbitmq-discuss] Duplicated message and unknown delivery tag after ack

[Tim Robertson]

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.

Sorry for the noise, and thanks Matthias for the quick answers



On Thu, Aug 8, 2013 at 3:21 PM, Tim Robertson <timrobertson100 at gmail.com>wrote:

> [stupidly I replied only to Matthias without noticing]
>
> 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.
>
> 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.
>
> Curiously, when I ran the rabbiteasy version through Tracer I got the
> following:
> http://pastebin.aquilenet.fr/?a91d27418ddaade5#8e6MBLhOR+ISSPEtg2QoR0iqURsGgBjBfCbH2dTaj9o=
> 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.
>
>
> On Thu, Aug 8, 2013 at 3:14 PM, Matthias Radestock <matthias at rabbitmq.com>wrote:
>
>> Tim, please keep the list in the loop on your investigation.
>>
>>
>> On 08/08/13 13:44, Tim Robertson wrote:
>>
>>> Thanks Matthias,
>>>
>>> I'm going to craft a vanilla consumer and try it.  I *don't think* this
>>> is related to the connection retrying, as this happens consistently and
>>> immediately when there is more than 1 thread registered with a channel.
>>>   The first consumer ACKs, but I *think* rabbit redelivers it anyway -
>>> more to follow on that.
>>>
>>> I only just started investigations, and came across this thread
>>> immediately.  It is curious we're both using totally different libraries
>>> (spring, rabbiteasy) and seeing the same behavior though.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Aug 8, 2013 at 12:47 PM, Matthias Radestock
>>> <matthias at rabbitmq.com <mailto:matthias at rabbitmq.com>**> wrote:
>>>
>>>     Tim,
>>>
>>>
>>>     On 08/08/13 11:39, Tim Robertson wrote:
>>>
>>>         Were there any further insights into this?
>>>         I am seeing the same behavior on 3.1.3 on my mac (homebrew
>>>         install) and
>>>         using rabbiteasy (1.2.0) and amqp java libraries 3.1.3.
>>>
>>>
>>>     rabbiteasy claims to provide "managed consumers that recover from
>>>     connection loss and re-attach to the broker". I strongly suspect
>>>     that recovery logic is too naive, allowing acks for messages to be
>>>     span channel recreation, which would result exactly in the error you
>>>     are seeing.
>>>
>>>     Regards,
>>>
>>>     Matthias.
>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130808/7c96194d/attachment.htm>