to check Queue and Exchange exists

[SG]

We are using fanout Exchange type,and configured exchange and queue in management UI console.

 

how to check Exchange and Queue exists before sending message to queue ??

 

how to capture to exception if queue or exchange does not exists ???

 

 

 

 

Thanks in advance.

[Michael Klishin]

On 23 August 2014 at 21:21:25, SG (gandh...@gmail.com) wrote:
> > how to check Exchange and Queue exists before sending message
> to queue ??

In general, you don't. You can just declare what you need (doing
so for every message is unnecessary, of course).

See https://groups.google.com/d/msg/rabbitmq-users/HhCZgE9_y6E/zwZUM2dLMvcJ
for more details.

> how to capture to exception if queue or exchange does not exists
> ???

If you really need to check that an exchange exists, declare it with
the passive property set to true. Then if it does not exist, a channel
error will be raised, which is handled as any other error (depends on
your client library of choice).

Checking that a queue exists before publishing makes little sense but
you can publish messages as mandatory, then if they can't be routed to
any queue, they will be returned to the publisher. 
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[SG]

Thanks MK.

 

but we are not declaring any exchange or queue.

 

we configured the exchange and queue in management console and we are using same.

 

can we check in this scenario ???

[Michael Klishin]

On 23 August 2014 at 21:34:22, SG (gandh...@gmail.com) wrote:
> > but we are not declaring any exchange or queue.
>
> we configured the exchange and queue in management console and
> we are using same.
>
> can we check in this scenario ???

Use passive declarations, e.g. on application start.

However, this is now how RabbitMQ protocol
was meant to be used. The apps are supposed to declare the topology they need
instead of a single centralised configuration tool. JFYI.

[SG]

Hi MK,

 

  is below code logic will check for exchange exists ???

 

using

(var connection = connectionFactory.CreateConnection())

{

using (var model = connection.CreateModel())

{

model.ExchangeDeclarePassive(

CommonService.ExcahangeName);

QueueDeclareOk ok = model.QueueDeclarePassive(CommonService.SerialisationQueueName);

if(ok.MessageCount > 0)

// Bind the queue to the exchange

model.QueueBind(

CommonService.SerialisationQueueName, CommonService.ExcahangeName, string.Empty);

// Set up message properties

var properties = model.CreateBasicProperties();

// Messages are persistent and will survive a server restart

properties.DeliveryMode = 2;

PublishMessages(model, properties, custList);

model.Close();

}

}

 

Thanks

SG

[Michael Klishin]

 On 23 August 2014 at 22:28:19, SG (gandh...@gmail.com) wrote:
> >
> using (var model = connection.CreateModel())
> {
> model.ExchangeDeclarePassive(CommonService.ExcahangeName);

Yes, this will. Note that if the exchange does not exist, the channel will
be useless after ExchangeDeclarePassive returns.

So using a temporary channel is a good idea. 

[SG]

Hi MK,

 

   Thanks for your clarification.

 

One final question on this .

 

we are already configured Exchange name in Managemnt console.

 

so ExchangeDeclarePassive() will check for that configured exchange exists or not ???

or will create any new exchange ???

 

 

Thanks

SG

[Michael Klishin]

On 23 August 2014 at 23:16:19, SG (gandh...@gmail.com) wrote:
> > so ExchangeDeclarePassive() will check for that configured
> exchange exists or not ???

It does nothing if the exchange exists.

> or will create any new exchange ???

"regular" exchange.declare is idempotent: if you re-declare
an exchange using exactly the same parameters, RabbitMQ won't
do anything.

I recommend reading the tutorials at
http://www.rabbitmq.com/getstarted.html 

[da...@bakins-bits.com]

This sure as hell surprised me just now (and I think it is broken).  The Javadoc for this method should definitely note this (which it doesn't, as of 3.5.6).  (I'm glad Google found this post...)

[Michael Klishin]

On 11 December 2015 at 01:48:12, da...@bakins-bits.com (da...@bakins-bits.com) wrote:
> This sure as hell surprised me just now (and I think it is broken).

I don't know if this counts as "broken" but this is how the protocol is supposed to work. I'm also not
sure how else it would work with client-defined entities ("last write wins" can be more confusing).

I'm not sure we'd be interested in explaining this for every *.declare method in every client
but a doc guide on queue and exchange properties is a good idea.

[da...@bakins-bits.com]

I don't know if this counts as "broken" but this is how the protocol is supposed to work. I'm also not
sure how else it would work with client-defined entities ("last write wins" can be more confusing).

Except we're not talking about writes: this is a check for existence ("passive") and to me it is very counterintuitive that a check for existence can fail the channel permanently.  Its sort of like a boolean File.exists() method that returns true if the file is there and throws an exception if it didn't and then you couldn't use the File class anymore.  If it reflects the protocol ... well, that's unfortunate ... but the Javadoc should warn you you're going to want to do this "check" with a throwaway channel. (*)

 

I'm not sure we'd be interested in explaining this for every *.declare method in every client
but a doc guide on queue and exchange properties is a good idea.

Only for *declarePassive, in the javadocs. But yes, something intermediate between the current client guide and the Javadoc would be nice.  Thanks! -- David

(*) I do understand that the normal declare is "idempotent" so why not just use it, which makes me wonder what the intended use case of the passive version is since it behaves this way.  Some situation where you want to use the exchange/queue if someone else set it up but don't want to create/use it if they didn't?

P.S. Is setting up a channel for throwaway purposes (like this) cheap, given you already have a connection?

[Michael Klishin]

On 11 December 2015 at 20:32:27, da...@bakins-bits.com (da...@bakins-bits.com) wrote:
> P.S. Is setting up a channel for throwaway purposes (like this)
> cheap, given you already have a connection?

Almost as cheap as a network round-trip can be.