Is it bad form to declare all queues and exchanges on every channel?

2
votes

I'm starting out with RabbitMQ and I have an architectural dilemma. I was about to build message consumer classes which declare the queues and exchanges they consume from and write to. In order to avoid mismatches in queue configuration options and names between multiple consumers and producers, I created a "repository" class which holds the queue names and options.

And then it struck me... Instead of having each consumer class contain the list of the queues it uses, why not have a global configChannel(Channel) static method which would declare ALL queues and exchanges for every channel I create? This way, I wouldn't have to worry about the order in which they're declared. Is there a downside? If not, why isn't this kind of approach recommended in the documentation (as far as I could see)?

edit

I found some more info here:

http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2013-June/027880.html

I think the expectation is that producers and consumers should declare the things that they directly interact with."

https://groups.google.com/forum/#!topic/rabbitmq-discuss/Jp49IRe693o

Typically, both the producers and consumers will declare the exchanges of interest. But only consumers will declare and bind the queues, because they know which messages they wish to receive.

If I understand correctly, to avoid messages getting black-holed (queue not declared yet) when the producer only declares the exchange it publishes to, some synchronization is necessary to make sure the consumer(s) is(are) started first and declares its(their) queue. Why bother with the potential trouble and not declare queues up front for every producer and consumer? I imagine there are applications which require dynamically created queues so that's another story. My argument pertains to the static or permanent application message queues when they exist.

1
rabbitmqmessage-queuemessaging
I would guess that it depends on how many queues are you are talking about. - robthewolf
For now, about 15 queues among which 3 are persistent. - bernie
queues cannot be persistent, messages are persistent, queues can be durable and they can be autodelete. I am a bit unclear on what you are trying to achieve here, but there should be no problem creating the queues ahead of time. - robthewolf
Sorry, I mixed-up the terminology. I meant to write 3 durable queues (which will contain persistent messages). I'm essentially asking: why not create the whole network of queues and exchanges for each channel at a single place instead of risking inconsistencies by declaring them piecewise? - bernie
What I do not understand is where the inconsistencies come from. The process of connecting to queue is the same as declaring one. So why create it ahead of time - robthewolf

1 Answers

0
votes

It turned out to be easier to declare queues, exchanges and bindings as an administrative step via a script.