Fanout binding produces amq.gen queues

[ofabel]

The fanout example produces 3 new amq.gen-... queues for each run. The problem is, this queues are not declared as exclusive, so they will persist until the server restarts. Is this the expected behaviour ? I suppose those are the answer queues for the fanout exchange message. But since the fanout exchange does not expect a response anyways i think they can be omitted or at least declared as temporary (like the answer queues from a direct binding).

[bombsimon]

Thanks for the report and sorry for the slow response!

Hmm, it's been a while since I worked with this code (and RabbitMQ in general) so I'm not completely sure how this should work. If I remember correctly, a client only creates one queue where all responses with this client will end up. A client can be used with multiple bindings, both fanout and direct. I don't think this is a problem? I saw in the documentation that no queue is ever declared for the client, but that example is only for a single fanout request.

For the server side however, this might be the problem the queue will be declared for the binding and never deleted. By just chaning the queue declare settings (which is already possible) we can better follow the documentation. I'll add a PR!

[ofabel]

No problem - and thanks for the response and the support!

We have solved the problem using a custom binding and set the queue name to something consistent:

binding := amqprpc.HandlerBinding{
    QueueName:    "some-queue-name",
    ExchangeName: "exchange-name",
    ExchangeType: amqprpc.ExchangeFanout,
    RoutingKey:   "",
    BindHeaders:  amqp.Table{},
    Handler: someHandlerFunc,
}

[bombsimon]

Awesome, glad to hear you fond a solution! Feel free to add a PR or suggest a proper solution if you want to and have the time for it. 🚀