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

[Chip Salzenberg]

Look closer and the inconsistency is clear.  In both cases the only problem
is that the client wants to consume from a queue, but the queue's
nonexistence makes that impossible.  Yet in one case the channel gets
closed; in the other, it doesn't.  Why should nonexistent queue at start be
a channel exception, but nonexistent queue later not be one?  Makes no
sense to me.  IMO neither case should be a channel exception.  Too late to
change it of course.

BTW the client code isn't general-purpose, so you need not worry that any
(other) users will be inconvenienced by my idiosyncrasy.


On Wed, May 1, 2013 at 10:16 PM, Michael Klishin <
michael.s.klishin at gmail.com> wrote:

> 2013/5/2 Chip Salzenberg <rev.chip at gmail.com>
>
>> The decision to close the channel is for symmetry with the "consume"
>> method, which closes the channel if it fails.
>
>
> When basic.consume fails, it is because you try to consume from a queue
> that does not exist or the queue is exclusive
> and owned by another connection. This raises a channel exception and that
> causes the channel to be closed.
>
> This is not specific to basic.consume but all channel exceptions. I
> personally don't think making cancellation notifications
> close a channel improves consistency. I'm not aware of other clients doing
> this.
> --
> MK
>
> http://github.com/michaelklishin
> http://twitter.com/michaelklishin
>
> _______________________________________________
> 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/20130502/341694cb/attachment.htm>