[rabbitmq-discuss] Duplicate Messages received after basicRecoveryAsync() is called.

[John Mann]

On Wed, Mar 3, 2010 at 8:00 AM, Matthias Radestock <matthias at lshift.net> wrote:
> John,
>
> John Mann wrote:
>>
>> I had no luck with calling basicCancel() and then waiting for the
>> handleCancelOK() method to be called.  I realized after stepping through the
>> source with a debugger that a Channel disassociates the Consumer when
>> basicCancel() is called:
>>
>> ChannelN.java: line 645:
>>
>>                Consumer callback = _consumers.remove(consumerTag);
>
> That codes is part of an rpc continuation. It gets called when the cancel-ok
> arrives, and the call to handleCancelOk happens right after the above line.
>
>> The only way that I knew I could reestablish this association was by
>> calling Channel.basicConsume().  Unfortunately this didn't work.  Messages
>> after that point were never delivered.
>
> Here is the sequence of client actions I proposed:
>
> 1) send basic.cancel
> 2) wait for basic.cancel-ok
> 3) send basic.recover
> 4) send basic.consume
>
> So you do indeed need a basic.consume to re-establish the consumer.
>
> One needs to be very careful with the threading here though. For example,
> the basic.consume must not be issued from the handleCancelOk callback. Doing
> so would most likely cause a deadlock. Perhaps that's what you were seeing.
>
> Anyway, I'm glad the channel close/re-open works as expected.
>

That's exactly what I was seeing.

> Anyway, I'm glad the channel close/re-open works as expected.

Me too.  Thanks again for your help.



-- 
-JC