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

[Tim Robertson]

[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/df4108fb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RabbitTest.java
Type: application/octet-stream
Size: 3575 bytes
Desc: not available
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130808/df4108fb/attachment.obj>