[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