[rabbitmq-discuss] After server notifies of canceled consume, it doesn't acknowledge a channel close

Chip Salzenberg rev.chip at gmail.com
Wed May 1 23:42:52 BST 2013


> (Bear in mind that the channel is not damaged by this, you don't have to
close it if you don't want to. But I can see you might want to.)

The decision to close the channel is for symmetry with the "consume"
method, which closes the channel if it fails.


On Wed, May 1, 2013 at 3:40 PM, Chip Salzenberg <rev.chip at gmail.com> wrote:

> I am using a modified AnyEvent::RabbitMQ Perl module (the standard one
> does not advertise its willingness to receive channel cancellations).  The
> module is event-driven; its input handler is not dependent on application
> logic, and is where I'm getting my frame dumps; and the module continues to
> send heartbeat frames even after other events stop.  Also, as an
> experiment, I arranged to send a CancelOk and got an error response (which
> was printed correctly).  So I do not believe the client is "hanging" in any
> sense.
>
> Does the Java automated test of close-after-cancel-notification expect a
> CloseOk?  Does it get one?
>
> How do you suggest dumping the frame traffic without depending on the
> suspect client module?
>
>
> On Wed, May 1, 2013 at 4:06 AM, Simon MacMullen <simon at rabbitmq.com>wrote:
>
>> On 01/05/13 05:16, Chip Salzenberg wrote:
>>
>>> I've successfully used the optional server feature of sending a
>>> basic.cancel when a consumed queue is deleted.  Great.  But a reasonable
>>> thing to do at that point is to close the channel, right?  But when I
>>> send a channel.close in that circumstance, RMQ 3.0.4 does not send a
>>> close-ok.  It doesn't send anything.  This makes my app hang.  I have to
>>> cheat and ass_u_me that the channel is closed in order to keep working.
>>>
>>
>> Well that definitely sounds wrong.
>>
>> (Bear in mind that the channel is not damaged by this, you don't have to
>> close it if you don't want to. But I can see you might want to.)
>>
>>
>>  Am I doing something wrong?  Is this a server bug?  Both?  :)
>>>
>>
>> I doubt it's a server bug; we have an automated test which closes a
>> channel after receiving a cancel notification. But Steve points out the way
>> in which the Java client could trip you up. In previous mails I think you
>> mentioned using the Perl client; possibly it has a similar limitation in
>> callbacks?
>>
>> If not, please post some example code and I will look into it.
>>
>> Cheers, Simon
>>
>> --
>> Simon MacMullen
>> RabbitMQ, VMware
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130501/f2f24d33/attachment.htm>


More information about the rabbitmq-discuss mailing list