[rabbitmq-discuss] 答复: Passive queue declaration and channel closure

[Simone Busoli]

David, I somewhat agree with you, lack of documentation about operational
aspects of broker behavior is something I have been missing as well. That
said it's usually not so difficult to overcome as it's fortunately quite
easy to explore the behavior of the broker under certain circumstances, and
it may take less than waiting for a reply on the mailing list!

On Sat, Feb 25, 2012 at 03:54, Liuzhuofu <liuzhuofu at huawei.com> wrote:

>  Hi all:
>     I have met the problem too. I know how to change my client code to fix
> it.
>     And I have a question, problem or skill like this can only be found in
> the mail-list, but there is no document describe them full-scale. In my
> opinion, this is a big  difficulty for all the developers on Rabbit-MQ.
>
>  Regards,
> David
>  ------------------------------
> *发件人:* rabbitmq-discuss-bounces at lists.rabbitmq.com [
> rabbitmq-discuss-bounces at lists.rabbitmq.com] 代表 Simone Busoli [
> simone.busoli at gmail.com]
> *发送时间:* 2012年2月22日 5:18
> *到:* Steve Powell
> *Cc:* rabbitmq-discuss at lists.rabbitmq.com
> *主题:* Re: [rabbitmq-discuss] Passive queue declaration and channel closure
>
>   Thanks Steve, that's pretty much what Simon had already clarified, and
> I agreed that changing this behavior is not practical.
> On Feb 21, 2012 2:24 PM, "Steve Powell" <steve at rabbitmq.com> wrote:
>
>> Simone,
>>
>> Replies in-line below..
>>
>> I don't think this is likely to change in the near future, since it
>> would be disruptive to most clients that use this.
>>
>> Steve Powell  (a happy bunny)
>> ----------some more definitions from the SPD----------
>> vermin (v.) Treating the dachshund for roundworm.
>> chinchilla (n.) Cooling device for the lower jaw.
>> socialcast (n.) Someone to whom everyone is speaking but nobody likes.
>>
>> On 16 Feb 2012, at 17:10, Busoli, Simone wrote:
>>
>> > Without relying on the management plugin I think the only way to do
>> that is to
>> > declare the queue as passive. At least with the .NET client and
>> apparently the
>> > Java client too, when the queue does not exist, besides throwing an
>> exception,
>> > the channel is closed as well. From the spec:
>> >
>> > If set, the server will reply with Declare-Ok if the queue already
>> exists with
>> > the same name, and raise an error if not. The client can use this to
>> check
>> > whether a queue exists without modifying the server state.
>>
>> The spec goes on to say:
>>
>>  The client MAY ask the server to assert that a queue exists without
>> creating
>>  the queue if not. If the queue does not exist, the server treats this as
>> a
>>  failure. Error code: not-found
>>
>> > There is no mention of channel closure, while the last sentence implies
>> that
>> > using the passive bit is indeed a way for a client to check queue
>> existence, so
>> > closing the channel when it doesn’t is a bit unexpected. That said,
>> it’s not a
>> > big deal to recreate the channel in such cases, but I’d appreciate your
>> opinion.
>> > Any chance this behavior can be changed in the client libraries?
>>
>> This is the mention of channel-closure -- an 'error' raised on the
>> channel will
>> close it.
>>
>> _______________________________________________
>> 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/20120225/b4345dff/attachment.htm>