[rabbitmq-discuss] Behaviour of Federated Queues

[Simon MacMullen]

On 23/01/2014 16:16, Josh West wrote:
> I have a question regarding the behaviour of federated queues...

<snip>

> 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 
to it?

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 
like broker1.*.

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
> other.

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 
to them.

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.

Cheers, Simon