Setting Default Policies for the RabbitMQ Service

Note: This version of RabbitMQ for Pivotal Platform is no longer supported because it has reached the End of General Support phase. To stay up to date with the latest software and security updates, upgrade to a supported version.

Note: Previous deprecation warnings for the pre-provisioned service are no longer in effect. Pivotal continues to support the pre-provisioned service.

About RabbitMQ Policies

You can set a default queue and an exchange policy in the RabbitMQ for Pivotal Cloud Foundry (PCF) tile to be applied to the RabbitMQ cluster. After you deploy the tile, Pivotal recommends that you use the RabbitMQ Management Interface to make configuration changes.

For more information about RabbitMQ policies, see the RabbitMQ documentation.

Rules for Policies Set in the Tile

The following rules apply to polices set through the RabbitMQ for PCF tile:

  • A new policy, or an update to a policy, only applies to new instances (vhosts). Existing instances are not affected by the policy.
  • The policy can only be deleted manually from the RabbitMQ nodes.
  • Policies can be added dynamically using the RabbitMQ Management Interface.
  • It is not possible to use pattern matching with policies. Policies will be applied to all queues and exchanges.

    For granular policy settings, Pivotal recommends using the RabbitMQ Management UI. Set a priority number lower than 50, the default priority number applied through the Ops Manager configuration.

An Example Policy: Mirror on Two Nodes

Here is an example policy that ensures messages are mirrored on two nodes:

{
  "ha-mode": "exactly",
  "ha-params": 2,
  "ha-sync-mode": "automatic"
}

Operators should consider some of the performance implications of making queues and exchanges highly available. For more information about highly available queues, see the RabbitMQ documentation.

Best Practice for Syncing Queues

When a queue syncs all its messages, they are loaded into memory. When queues are syncing, they can use as much memory as the total size of all messages. This applies to both nodes—the node where the queue leader runs (from node) and the node where the queue follower runs (to node), but only applies to newly created queue followers.

This behavior is especially relevant when any change affects the deployment, for example: stemcell updates, deployment configuration changes, and network changes. Verify that you have enough memory and disk available to support all messages.

For example:

There are 5 GB of messages in a mirrored queue that is set to automatic sync. When this queue needs to sync, the node where the queue leader runs can use up to 5 GB of extra memory. The same applies to the node where the new queue follower is created.

Setting or Changing the Policy

To set the RabbitMQ policy, do the following:

  1. From the Ops Manager Installation Dashboard, click the RabbitMQ for PCF tile and then click the Pre-Provisioned RabbitMQ tab.

    Policy opsman

  2. Select Enable custom policy on new instances.

  3. In the Policy for new instances field, paste the policy.

    The policy must be valid JSON and should meet valid RabbitMQ policy criteria.

Note: No policy validation occurs during the deployment, and errors can cause the deployment to fail or policies to be applied incorrectly.

Viewing Policies in the RabbitMQ Management UI

You can view RabbitMQ policies in the RabbitMQ Management UI, shown below. The example policy entered in the RabbitMQ for PCF tile above is applied to all queues and given a Priority of 50. This allows you to override it by defining another policy with a higher priority.

Policy config

In the Queues section shown below, you can see that any new queues created have the policy automatically applied.

Policy queue

Note: Developers can obtain the URL of the policy from VCAP_SERVICES for app developers.

Was this helpful?
What can we do to improve?