[rabbitmq-discuss] A note on queue federation and upgrades to 3.2.0

Simon MacMullen simon at rabbitmq.com
Wed Oct 23 17:43:15 BST 2013

tl;dr version: if you define "federation-upstream-set" and "ha-mode" *in 
the same policy definition*, you might need to take action when 
upgrading. We hope this won't apply to many people; mostly 
"federation-upstream-set" and "ha-mode" would be used in distinct policies.

Longer version:

So RabbitMQ 3.2.0 was released today (woo!) A headline feature is 
federated queues. But obviously you only want your queues to be 
federated if that's what you chose, your queues should not just become 
federated when you upgrade.

Queue federation in 3.2.0 is controlled by the same 
"federation-upstream-set" policy definition that controls exchange 
federation. But this gives us a problem - you might previously have had 
a federation policy that coincidentally matched some queues, but did 
nothing as a consequence. We don't want those queues to suddenly become 
federated without asking! So 3.2.0 introduces a new feature for 
policies: you can decide whether you want your policy to match just 
exchanges, just queues or both.

During the upgrade process to 3.2.0 we look at your policies and decide 
for each one whether it should match exchanges, queues or both. We do 
this by looking for "federation-upstream-set" and "ha-mode" definitions. 
If there's a "federation-upstream-set" definition, we assume the policy 
is meant to match exchanges. If there's an "ha-mode" policy, we assume 
it should match queues. And if it contains both, we assume it should 
match both.

So in the latter case the queue might start trying to federate. Assuming 
you don't want that, you should split the policy into two - one that 
matches exchanges only and defines "federation-upstream-set", and one 
which matches queues only and defines "ha-mode".

Cheers, Simon

Simon MacMullen
RabbitMQ, Pivotal

More information about the rabbitmq-discuss mailing list