Policies – RabbitMQ for MSMQ users, part 4

What is RabbitMQ policy?

Policy is a way to centralize management of queue properties. It’s common that queues which are used for similar things have the same configuration. For example, they could have same “time to live”, or deadletter settings. Instead of setting up the same list of settings for each queue, which is time-consuming and error-prone, you can create a policy which contains all these mutual settings, and then apply it to a set of queues. That way settings are defined in one place and shared where needed.

If queue has some argument set, it has higher priority and overrides what’s configured in a policy.

Btw. policies can be also applied to exchanges, but since they work the same way we won’t discuss that separately.

You can’t reconfigure queues or exchanges

In RabbitMQ, you can’t change any property of queue or exchange once it’s created. The only things you can edit are bindings. So if you need to change anything else, you’ll have to delete existing object and create a new one. That’s problematic if object is in use, with messages flowing in and out. However, policies are editable. If queue settings are configured through a policy, they can be changed.

Choosing queues where policy is applied

Unfortunately, RabbitMQ doesn’t offer you to go to a queue and say “I want this policy to apply to this queue”. Instead, you have to go to a policy and enter a regular expression pattern. Policy is then applied to all queues which name matches that patter. Since it’s kind of awkward to create a regular expression to match arbitrary queue names, it helps if your queues have structured names, like “order.incoming”, “order.errors”, etc. or something similar which is easier to match. It’s easier to set up a pattern which would apply to all “.error” queues.

QueueExplorer allows you to see which policy and which settings from it will be applied to a queue:

Conflicting policies

Only one policy can be applied to a single queue. That’s why policies have priorities. If you have two or more policies whose patterns match the same queue, the one with higher “priority” will be used. If policies have the same priority, RabbitMQ will choose one nondeterministically, i.e. more or less random, so that’s not something we should ever rely on.

Operator policies

There are some cases where an administrator would want to override some of the settings from regular policies. Operator policies offer a way to do that, but only for following arguments:

• expires
• message-ttl
• max-length
• max-length-bytes

Important difference is that operator policy is merged with a regular policy if there’s any. If there’s the same argument defined in both regular and operator policy, a smaller value is used. That can work since all of these 4 applicable settings are numeric. That also means that operator policy can be used to make some of these arguments lower, but not higher than specified elsewhere.

In the next part we’ll talk about distributed brokers.

Links to all 6 parts of this series.