[rabbitmq-discuss] Duplicate Messages received after basicRecoveryAsync() is called.
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