Getting a queue without providing its all properties
Asked Answered
U

3

6

I am trying to write a consumer for an existing queue.

RabbbitMQ is running in a separate instance and queue named "org-queue" is already created and binded to an exchange. org-queue is a durable queue and it has some additional properties as well.

Now I need to receive messages from this queue. I have use the below code to get instance of the queue

conn = Bunny.new
conn.start
ch = conn.create_channel    
q = ch.queue("org-queue")

It throws me an error stating different durable property. It seems by default the Bunny uses durable = false. So I've added durable true as parameter. Now it states the difference between other parameters. Do I need to specify all the parameters, to connect to it? As rabbitMQ is maintained by different environment, it is hard for me to get all the properties.

Is there a way to get list of queues and listening to the required queue in client instead of connecting to a queue by all parameters.

Underplay answered 16/2, 2016 at 10:33 Comment(2)
Typically when you interface with a message bus you're supposed to know the contract you need to uphold - doing it dynamically as you're suggesting can create various problems and can be VERY hard to debug. I wouldn't recommend itVictualler
I second that. You should have the parameters used to set up the queues somewhere in an environment variable and connect to the queue/exchange using those.Honewort
C
2

Have you tried the :passive=true parameter on queue()? A real example is the rabbitmq plugin of logstash. :passive means to only check queue existence rather than to declare it when consuming messages from it.

Caelian answered 26/2, 2016 at 2:35 Comment(0)
K
1

Based on the documentation here http://reference.rubybunny.info/Bunny/Queue.html and http://reference.rubybunny.info/Bunny/Channel.html

Using the ch.queues() method you could get a hash of all the queues on that channel. Then once you find the instance of the queue you are wanting to connect to you could use the q.options() method to find out what options are on that rabbitmq queue.

Seems like a round about way to do it but might work. I haven't tested this as I don't have a rabbitmq server up at the moment.

Kwapong answered 25/2, 2016 at 22:57 Comment(1)
For me ch.queues() returns an empty hash though queues are present in my rabbitMQ serverUnderplay
M
0

Maybe there is way to get it with rabbitmqctl or the admin tool (I have forgotten the name), so the info about queue. Even if so, I would not bother.

There are two possible solutions that come to my mind.

First solution:

In general if you want to declare an already existing queue, it has to be with ALL correct parameters. So what I'm doing is having a helper function for declaring a specific queue (I'm using c++ client, so the API may be different but I'm sure concept is the same). For example, if I have 10 subscribers that are consuming queue1, and each of them needs to declare the queue in the same way, I will simply write a util that declares this queue and that's that.


Before the second solution a little something: Maybe here is the case in which we come to a misconception that happens too often :) You don't really need a specific queue to get the messages from that queue. What you need is a queue and the correct binding. When sending a message, you are not really sending to the queue, but to the exchange, sometimes with routing key, sometimes without one - let's say with. On the receiving end you need a queue to consume a message, so naturally you declare one, and bind it to an exchange with a routing key. You don't need even need the name of the queue explicitly, server will provide a generic one for you, so that you can use it when binding.


Second solution: relies on the fact that

It is perfectly legal to bind multiple queues with the same binding key (found here https://www.rabbitmq.com/tutorials/tutorial-four-java.html)

So each of your subscribers can delcare a queue in whatever way they want, as long as they do the binding correctly. Of course these would be different queues with different names. I would not recommend this. This implies that every message goes to two queues for example and most likely a message (I am assuming the use case here needs to be processed only once by one subscriber).

Moon answered 23/2, 2016 at 23:4 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.