When to declare/bind Queues and Exchanges with RabbitMQ

Question

We have a wrapper library around RabbitMQ at my workplace, created by someone who no longer works here. I'm designing a new system using Rabbit, and am working out the best approach for declaring queues, exchanges and bindings. Our Rabbit architecture has a few federated global zones, and each zone has multiple Rabbit nodes.

The wrapper code to publish messages and subscribe to queues re-declares the relevant exchanges, queues and bindings each time. My concern is that this may introduce significant latency into every message publish, especially if it needs to wait for confirmation the queue/exchange exists in the remote global zones. I expect the benchmark of millions of messages a second don't re-declare the exchange for each publish.

In short, this approach seems a bit wasteful and paranoid to me, but perhaps I'm missing something.

So I have a few questions:

• Is re-declaring the queues and exchanges a significant performance hit, given global federation?
• Is re-declaring on each use a good approach because it handles queues/exchanges disappearing due to broker restarts or explicit deletion?
• Should we just declare queues and exchanges once per process and expect them to last the whole lifetime?
• Should durable exchanges and queues be declared in Rabbit config and not declared by the applications at all?
• How should config changes for queues/exchanges be handled if applications may continue to declare them with old config? Should applications just handle the declare failure and continue to publish/consume?

Answer 1

Is re-declaring the queues and exchanges a significant performance hit

it can be for a very large volume of messages

Is re-declaring on each use a good approach because it handles queues/exchanges disappearing due to broker restarts or explicit deletion?

"good approach" - no.

"effective" at preventing disappeared exchanges / queues / bindings from causing problems, yes... but it's not a good thing to do, in most cases

(maybe ok if you only send a message very infrequently, there is a real cause for concern about the topology being wiped clean)

Should we just declare queues and exchanges once per process and expect them to last the whole lifetime?

this is my general approach.

it opens the possibility of topology being destroyed and you not knowing it. it comes down to whether or not you think this will really happen.

Should durable exchanges and queues be declared in Rabbit config and not declared by the applications at all?

there's nothing wrong with pre-defined topology, but it misses a lot of the power and flexibility of rabbitmq and the amqp protocol.

many messaging systems require predefined topologies and specialized tools to manage the topology. amqp is quite different in that it allows you to define the topology as needed.

if you deal with a static topology, then this might be a good option for you

How should config changes for queues/exchanges be handled if applications may continue to declare them with old config? Should applications just handle the declare failure and continue to publish/consume?

i would crash the app and report it through whatever error reporting mechanism you are using.

having a topology change is usually something important, and done for a reason. if the exchange or queue declaration needs to change, there is probably a good reason for it and the code should not continue with the old declaration.