tile38
tile38 copied to clipboard
tidwall
AMQP is Subscribing for all the messages it is producing
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.
Interesting. Are the QueueDeclare and QueueBind calls doing anything at all, or are they just no-ops?
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
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.
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.
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.
