LangJV
commented
1 year ago To provide some clarity on this. When using a "complete graph" or "full topology" Federation policy as described here: https://www.rabbitmq.com/federated-exchanges.html#topology-diagrams Where all nodes are both upstream and downstream of each other, deleting a queue can become impossible.
When a federation setup is in place, and you attempt to delete a queue using amqps, http API, etc. The queue will successfully delete, and "sometimes" be re-created a few milliseconds to seconds later via the "federation user". This results in the queue still existing, but now having no federation connections, consumers, etc.
At minimum, the deletion operation should be consistent, that is it can fail and return a message "you cannot delete a federated queue" but generally speaking, I (believe) i should be able to consistently and reliably delete a federated queue in rabbitMQ. Either by propagating the deletion call to all federated node(s) to fully process, or having something in place to prevent it being immediately re-created. Even when i simultaneously process the "delete" call on all federated clusters simultaneously, it will intermittently come back "sometimes" in one or more of hte clusters due to federation re-creating it.
In some environments, federation's periodic redeclaration of federated queues conflicts with what applications do (namely when applications delete those queues).
It might be possible to extend queue federation policy with a parameter that would control whether the plugin should perform periodic redeclarations on said queues or declare them just once.