AMQP is Subscribing for all the messages it is producing

tidwall / tile38

Real-time Geospatial and Geofencing

https://tile38.com

MIT License

9.09k stars 569 forks source link

AMQP is Subscribing for all the messages it is producing #606

Open pacaj2am opened 3 years ago

pacaj2am commented 3 years ago

When publishing to Direct, Topic or Fanout exchange (e.g.: amqp://guest:guest@localhost/myExchange?type=topic) no Queue and no Queue Binding needs to be done. Only simple publish is sufficient with Exchange name instead of Queue name.

as described in Rabbit tutorial.

pacaj2am commented 3 years ago

Created pullrequest: https://github.com/tidwall/tile38/pull/607

tidwall commented 3 years ago

Interesting. Are the QueueDeclare and QueueBind calls doing anything at all, or are they just no-ops?

pacaj2am commented 3 years ago

Basically they are doing the job of the consuming application.

The consuming application is creating a queue and binding it to the exchange. But the consuming app should have that in control, it can configure other stuff like:

get messages from more exchanges to one queue
make them autodelete, when the connection to rabbit is closed (there are no messages stacked in queue, when the application is not running)
make it exclusive - that any other application can't take by error the messages from the queue

tidwall commented 3 years ago

Ok, just so I understand. So you are suggesting removing those two calls from Tile38 because they should only be used by the consumer application. And, removing them will do nothing to affect the current behavior of Tile38 or anyones AMQP configurations.

pacaj2am commented 3 years ago

This removal might affect current AMQP configurations. Cleanest solution is to put a parameter not to create the queue and binding. And in some major release to reverse - to do that only if one needs that. I am not a go developer, that is something beyond my skills.

uwer commented 1 year ago

Hi Guys, i can see the pull request, has this been accepted ? I am facing a very similar challenge and i do agree to some extent with pacaj2am - however queue creation and binding should only be removed for certain exchanges - i.e. topic. AMQP is a bit of a special case (in a good way) in the way it handles distribution of messages. Restricting it this way would also retain the current default operation. Context: for topic exchanges - associated queues get delivered messages based on the routing key and wildcard, which is what most people wold be after.