How to unbind queue from exchange using REST API?

[Jac Wi]

Hi All,

I managed to bind queue to exchange using REST API using this:

/api/bindings/vhost/e/exchange_name/q/queue_name

However, I don't know how to unbind it. I've tried with DELETE but got no success.

Thank you in advance.

[Michal Kuratczyk]

Given your previous question, I'm not sure you should be doing this. When you subscribe to an MQTT topic, RabbitMQ implements that by creating a queue and binding it to a topic exchange with the right routing key, which is exactly what you seem to be doing manually. As I mentioned in the other thread, if you want this queue to stay there when the client disconnects, just declare your MQTT session as persistent/non-clean. When you do that, a persistent queue is created and bound (otherwise the queue is declared as auto-delete and deleted when the client disconnects).

Answering your question, since bindings have no names, it is a bit tricky but here's an example of how rabbit-hole does it (rabbit-hole is a Go client for the REST API - you can use this library or do what it does):

https://github.com/michaelklishin/rabbit-hole/blob/master/bindings.go#L211-L229

Best,

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/82777a5c-8c0a-4301-b872-5c86abc90e62n%40googlegroups.com.

--

Michał

RabbitMQ team

[Jac Wi]

Hi Michal,

Thank you and sorry for the late reply. I understand that when a client connects to broker, RabbitMQ will automatically create the queue and bind it to the default queue (amq.topic). However, I need more than this. 

Besides the auto-create queue, every user (client) will also have a unique "fanout" topic. By binding other users' queues to this "fanout" topic, the topic owner can simply publish a message to his/her unique "fanout" topic. Then all the bounded queues will automatically receive the message. Queues that are not bounded will not receive the message. Correct me if I'm wrong.

That's why I need to bind interested user's queue to that "fanout" topic. Again this is not just a single fanout topic, since every user will have his/her own unique fanout topic.

Hope this can explain better. 

Thank you in advance.

[Jac Wi]

Sorry, I forgot to tell that I can't use routing-key, since all the queues are having the same "mqtt-subscription-*qos1" leading key. So it's impossible to differentiate which queues must receive the message and which queues must not.

Regards,

Jac

[Michal Kuratczyk]

I'm afraid I'm still not sure whether you found a limitation in our MQTT implementation (at least in the context of your use case) or our docs and my explanation are not clear enough (or I just don't understand your use case).

If I start 2 subscribers (I use this for testing: `emqtt_bench sub -V3  -c1  --topic t1`), I can see the following bindings:

$ rabbitmqctl list_bindings

source_name source_kind destination_name destination_kind routing_key arguments

amq.topic exchange mqtt-subscription-mkuratczyk-a01_bench_sub_2_2844951299qos0 queue t1 []
amq.topic exchange mqtt-subscription-mkuratczyk-a01_bench_sub_2_3044852058qos0 queue t1 []

So I have two queues (mqtt-subscription-*) and both are bound to amq.topic exchange with the routing key "t1". If the topic owner wants to communicate with the subscribers interested in t1, all it has to do is publish a message to amq.topic exchange with the key "t1". Standard RabbitMQ mechanisms (exchange/routing) will make it so that both queues, and therefore subscribers, will receive that message. If I run additional subscribers with a different topic, they will bind to the same amq.topic exchange but will only receive messages for their topic (say, "t2"). Again - all the owner has to do is publish a message to amq.topic with the appropriate routing_key. So all you need is 1 topic exchange, RabbitMQ will automatically create a queue and binding for each subscription. I still don't see why you would need additional exchanges and bindings.

Best,

To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/89921463-a9ef-4575-91fd-df8d3d4809f5n%40googlegroups.com.

--

Michał

RabbitMQ team

[Jac Wi]

Hi Michal,

I tried the above command and got this result:

rabbitmqctl list_bindings --vhost vhost_name

Listing bindings for vhost vhost_name...

source_name     source_kind      destination_name           destination_kind        routing_key                arguments

exchange        mqtt-subscription-ClientID1qos1 queue    mqtt-subscription-ClientID1qos1 []

exchange        mqtt-subscription-ClientID2qos1 queue    mqtt-subscription-ClientID2qos1 []

The above bindings automatically occured during first time "connect" only. I don't do any subscription when connecting the client to broker.

Not sure why, I didn't get the "amq.topic" under "source_name". But that's ok, because it's working though, by publishing the message using the appropriate routing_key to get to the specific client.

The problem is, when I subscribe from MQTT Client to "vhost_name/fanout/ClientID1" from client2 (client3, client4, etc), I don't see any binding using the above command. Perhaps there is a problem with the MQTT client part, I'll find out about that.

That's why I tried the "exchange-to-queue" bindings using the REST API, to make sure when I publish the message to  "vhost_name.fanout.ClientID1" exchange, all the bounded clients' queues will receive the message. Unfortunately, I don't know how to UNBIND it.

Regards,

Jac

[Michal Kuratczyk]

Ok, I'm pretty sure you have a problem on the client side - the client doesn't subscribe to the topic it should.

I'd highly advise against manually creating exchanges and bindings to overcome this kind of problem.

RabbitMQ does exactly what you need (as far as I can tell). Rebuilding the same behaviour manually is just asking for trouble.

It may be fairly simple to make it work for the common case but over time, I'm pretty sure you'll experience stale subscriptions,

leftover exchanges/bindings/queues, etc. Instead of going through the trouble, just make sure your clients correctly subscribe and everything should work.

As for deleting the bindings - I shared links to the code that does it. You can use that code (rabbit-hole is a client lib for such operations)

or you can implement the same REST call in your code.

Best,

To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/d14e0566-041f-4fa4-8d43-a08da3d00fcan%40googlegroups.com.

--

Michał