{"id":263,"date":"2018-04-20T12:20:20","date_gmt":"2018-04-20T11:20:20","guid":{"rendered":"https:\/\/www.cogin.com\/blog\/?p=263"},"modified":"2018-04-26T10:41:13","modified_gmt":"2018-04-26T09:41:13","slug":"policies-rabbitmq-for-msmq-users-part-4","status":"publish","type":"post","link":"https:\/\/www.cogin.com\/blog\/rabbitmq\/policies-rabbitmq-for-msmq-users-part-4\/","title":{"rendered":"Policies – RabbitMQ for MSMQ users, part 4"},"content":{"rendered":"

What is RabbitMQ policy?<\/h2>\n

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.<\/p>\n

\"\"<\/p>\n

If queue has some argument set, it has higher priority and\u00a0overrides\u00a0what’s configured in a\u00a0policy.<\/p>\n

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

You can\u2019t reconfigure queues or exchanges<\/h2>\n

In RabbitMQ, you can\u2019t change any property of queue or exchange once it\u2019s created. The only things you can edit are bindings. So if you need to change anything else, you\u2019ll have to delete existing object and create a new one. That\u2019s 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.<\/p>\n

Choosing queues where policy is applied<\/h2>\n

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

QueueExplorer<\/a> allows you to see which policy and which settings from it will be applied to a queue:<\/p>\n

\"\"<\/p>\n

Conflicting policies<\/h2>\n

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\u00a0same queue, the one with higher “priority” will be used. If policies have the same\u00a0priority, RabbitMQ will choose one nondeterministically, i.e. more or less random, so that’s not something we should ever rely on.<\/p>\n

Operator policies<\/h2>\n

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:<\/p>\n