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

Matthias Radestock matthias at lshift.net
Wed Mar 3 13:00:10 GMT 2010


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.



More information about the rabbitmq-discuss mailing list