[rabbitmq-discuss] Behaviour of Federated Queues
simon at rabbitmq.com
Fri Jan 24 12:20:47 GMT 2014
On 23/01/2014 16:16, Josh West wrote:
> I have a question regarding the behaviour of federated queues...
> I have noticed that if I create a queue on broker1 with name
> "broker1.foo.bar" (for example), the queue is automatically created on
> broker2 and broker3. Should this occur? Or should federation only
> create the queue on upstream brokers when needed (ad-hoc)?
It should occur. I'm not sure when 'needed' would be; when you publish
If your aim is to make sure that you can publish anywhere and have the
publishing application determine which node the message ends up on, you
might find that exchange federation works better for you; have a single
federated exchange and bind (unfederated) queues to it with routing keys
Not that federated queues are necessarily bad in this scenario, but yes,
you'll have a lot of queues around.
> I ask for two reasons:
> 1. This could be a waste of resources if one has lots of queues matching
> federation patterns or if one has say 200+ brokers federated with each
200 queues is not actually a huge number. Plenty of people have many
thousands of queues.
> 2. When queues are created with the Auto Delete parameter, that
> parameter is of course properly propagated. But say a client puts a
> message into the queue "broker1.foo.bar" on broker2 and say a client
> retrieves the message from that same queue on broker1. The Auto Delete
> parameter behaviour would be triggered and the queue is then deleted
> from broker1 and broker2 (upon client disconnection). But... Since
> nobody has ever put any messages into the queue "broker1.foo.bar"
> residing on broker3, the queue will remain defined possibly indefinitely.
That's not how autodelete works - queues autodelete when their last
consumer goes away, regardless of whether messages have been published
So I see this working correctly - when a consumer consumes from
broker1.foo.bar on broker1, that consumer gets propagated to
broker1.foo.bar on broker3. When the consumer is cancelled, cancel is
also propagated and both queues delete.
However, I think there is the opposite problem around auto-delete and
queue federation - since the federation mechanism controls message flow
by consuming and cancelling from the upstream, it could cause federated
autodelete queues to delete themselves too early.
I'm not sure what, if anything, can be done about that. It might be that
autodelete and queue federation just don't work well together.
More information about the rabbitmq-discuss