[rabbitmq-discuss] Passive queue declaration and channel closure

Fri Feb 17 13:15:40 GMT 2012

Thanks for the explanation Simon, I was missing that it was the server triggering the channel closure, while I assumed it was just the client behavior when responding to an error from the server. I concur that it's not an easy change for the client library then.

-----Original Message-----
From: rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of Simon MacMullen
Sent: venerdì 17 febbraio 2012 13:32
To: rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] Passive queue declaration and channel closure

On 16/02/12 17:10, Busoli, Simone wrote:
> Hi, I'm revamping this
> <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2011-February/01
> 1314.html> old thread because I'm trying to solve pretty much the same 
> problem. I need to know whether a queue that I have declared still 
> exists on the server or has for any reason been deleted.
>
> Without relying on the management plugin I think the only way to do 
> that is to declare the queue as passive.

Yes.

> 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.

It's the server closing the channel really. The channel closure causes the exception to be thrown, not the other way around.

> 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.
>
> 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.

The key phrase is "raise an error". This is defined to always close the channel (and sometimes the connection too depending on the error code) in AMQP.

> 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?

It's probably slightly easier to open a new channel just to issue the queue.declare then close it anyway. That's what I'd do.

It's not really the client's purview, and currently the only way for the server to indicate an error is to close *something* anyway, so this isn't a trivial change...

Cheers, Simon

--
Simon MacMullen
RabbitMQ, VMware
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

_________________________________________________________________________________________________________________
Questo messaggio è da intendersi esclusivamente ad uso del destinatario e può contenere informazioni che sono di natura privilegiata, confidenziale
o non divulgabile secondo le leggi vigenti. Se il lettore del presente messaggio non è il destinatario designato, o il dipendente/agente responsabile
per la consegna del messaggio al destinatario designato, si informa che ogni disseminazione, distribuzione o copiatura di questa comunicazione è 
strettamente proibita anche ai sensi del decreto legislativo 196/03 . Se avete ricevuto questo messaggio per errore, vi preghiamo di notificarcelo
immediatamente a mezzo e-mail di risposta e successivamente di procedere alla cancellazione di questa e-mail e relativi allegati dal vostro sistema.
_________________________________________________________________________________________________________________
This message is intended only for the use of the addressee and may contain information that is privileged, confidential and exempt from 
disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly 
prohibited. If you have received this e-mail in error, please notify us immediately by return e-mail and delete this e-mail and all attachments from 
your system.
_________________________________________________________________________________________________________________