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

Thu Aug 8 15:45:10 BST 2013

This is the rabbiteasy issue, should anyone stumble upon this thread.
https://github.com/zanox/rabbiteasy/issues/4
Disclaimer: I could be using rabbiteasy wrong of course, but I _don't
think_ I am.

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

> 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/3a11272d/attachment.htm>