[rabbitmq-discuss] channel.basicCancel hangs

Steve Powell steve at rabbitmq.com
Wed May 22 15:42:22 BST 2013


Hi Kristian,

This behaviour seems incorrect: you should not block forever waiting for
the Basic.CancelOk reply to come back. There could be a number of
reasons for this but you *shouldn't* have to acknowledge all messages
before being able to cancel a consumer.

I wonder if the consumer is executing other channel methods in its
callbacks? Possibly Ack, which should be ok; possibly other methods.

It is entirely possible for consumer callbacks
(handleDelivery/handleCancel/handleCancelOK etc.) to be called *after*
you have called the basicCancel() method.

There are two reasons for this -- one is that the communications with the
server are asynchronous: deliveries might continue to be made after
sending the Cancel frame and before getting the CancelOk reply.

The other reason is that requests to call the callbacks are queued, and
executed on their own thread in sequence for each channel. A number of
callbacks may be queued when the basicCancel() method is called. They
may not have finished executing even when the reply to the basic.cancel
is received (Basic.CancelOk). Only when the reply is received is the
call to handleCancelOk() put on the queue for execution, so that it is
the last callback to be executed.

For these reasons, you shouldn't consider the Consumer to be stopped
properly until the last callback (handleCancelOk() or handleCancel())
has been called.

If one of the callbacks being processed makes a blocking call, even this
shouldn't block the reply unless it blocks the channel somehow. So what
could? I don't know, unless you are issuing a channel.close() or
something in your consumer callback methods. There could be a bug here
we ought to know about.

If you have a stack dump at the point of the hang (jstack is probably
the easiest way to get this) we should be able to tell what the other
threads are doing, and then get a clue as to why you are blocked. The
main thread that is hung is likely to be uninteresting -- it is probably
waiting for the Basic.CancelOk frame to be received (on a getReply()
call).

So please could you tell us a little more about your application? In
particular, what is your Consumer like? Are the handleDelivery()
callbacks doing some unusual work with the channel, for instance?
Anything that would help us get to the bottom of this would be useful.

Steve Powell  [Cell: +44-7815-838-558]
Links: Pivotal, SpringSource, VMware, Virgo, RabbitMQ.
-----------------------------------------------------------------------
Good design:
   is innovative, useful, aesthetic;
   is understandable, unobtrusive, honest;
   is long-lasting, thorough, environmentally friendly;
   and is as little design as possible.
Copyright Dieter Rams, amended March 2003; October 2009; and August 2012

On 22 May 2013, at 02:19, Kristian Lind <klindp at gmail.com> wrote:

> I found the problem... I had a message that was not ack.. so now before closing the channel I ack the msg._______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130522/0e66de5e/attachment.htm>


More information about the rabbitmq-discuss mailing list