Release Notes
Announcements
Configuring the Custom Policy
Scenarios
In TDMQ for RabbitMQ, when creating a queue or exchange, in addition to required properties (such as Durable and Exclusive), users can also configure optional properties (such as x-message-ttl, x-expires, and x-max-length) to implement different features.
Note that after a queue or exchange is created, its property parameters cannot be directly modified unless you delete and recreate it.
To enhance flexibility, RabbitMQ provides a policy mechanism. A policy is a special method for configuring runtime parameters. It supports dynamic adjustment of certain properties. Policies operate at the vhost level and can match one or more queues/exchanges, thereby enabling batch management. Through policies, we can bypass the limitation that queue/exchange properties cannot be directly modified, significantly improving Ops efficiency.
This document introduces how to customize policies in the console.
Use Limits
Configuration of custom policies is supported only for Managed Edition clusters and is not currently supported for Serverless Edition clusters.
Operation Steps
Creating a Custom Policy
If mirrored queues are enabled during the creation of a cluster, a default policy will appear under the Policy tab in the console. You may delete this policy or create and modify a policy.
1. Log in to the TDMQ for RabbitMQ console.
2. In the left sidebar, choose Cluster > Vhost. Select the target region and click the name of the target vhost to go to the Basic Information page.
3. Choose Policy > Create Policy and enter the basic policy information.
Basic settings
Parameter | Description |
Current Vhost | Indicates which vhost the mirroring policy is being created for. |
Policy Name | Enter a policy name. It must be 1 to 64 characters in length and can only contain digits, letters, periods (.), hyphens (-), and underscores (_). |
Match Mode | A regular expression used to match relevant queues or exchanges. For common regular expressions of match modes, see: .*: Match all queues or exchanges under this vhost. ^test.*: Match all queues or exchanges under this vhost whose names start with "test". .*test.*: Match all queues or exchanges under this vhost whose names contain "test". .*test$: Match all queues or exchanges under this vhost whose names end with "test". |
Policy Type | Select Custom Policy. |
Application Scope | Used to specify the effective scope of the current policy. Exchanges and queues: indicate that the current policy applies to all queues or exchanges matching the mode. Queues: indicate that the current policy applies to all queues matching the mode. Exchanges: indicate that the current policy applies to all exchanges matching the mode. |
Priority | Defines the policy priority, which ranges from 0 to 255. If multiple policies apply to the same queue or exchange, only the policy with the largest priority number takes effect. |
Policy Configuretion
You can select the required policy definition fields yourself, as shown in the figure below.
Currently, the fields supported by the cloud console are listed in the table below. For additional fields, create them in the open-source console.
Field Classification | Field Name | Description | Data Type Restriction |
Queues (All Types) | Max Length | Maximum number of messages allowed in the queue. When the number of messages in the queue reaches this limit, old messages will be deleted, or new messages will be rejected according to the Overflow Behaviour settings. | Number |
| Max Length Bytes | Maximum total bytes of messages allowed in the queue. When the total bytes of messages in the queue reaches this limit, old messages will be deleted, or new messages will be rejected according to the Overflow Behaviour settings. | Number |
| Overflow Behaviour | Handling method when the queue reaches the maximum length or maximum bytes. Valid values: drop-head: Delete old messages at the head of the queue. reject-publish: Reject newly published messages. reject-publish-dlx: Reject newly published messages, and route the rejected messages to the dead letter exchange configured for the queue. | String |
| Auto Expire | Auto-expiration time of the queue. The unit is milliseconds. When the queue is not accessed (for example, no messages are published or consumed, or the queue status is not checked) within this time, the queue will be deleted. | Number |
| Dead letter exchange | Dead letter exchange. When messages are deleted due to exceeding the time to live (TTL), reaching the maximum queue length, or being rejected by consumers, they will be sent to the specified dead letter exchange. | String |
| Dead letter routing key | Dead letter Routing Key. This Routing Key can be used for routing when a message is sent to the dead letter exchange. | String |
Queues [Classic] | Message TTL | Message TTL. The unit is milliseconds. This value defines the maximum duration a message can stay alive in the queue. A message will be deleted when its TTL in the queue exceeds this value. If the message is consumed (and confirmed) by the consumer or re-published to other queues, the timer will be reset. | Number |
| Lazy mode | Lazy mode. When this mode is enabled, RabbitMQ will store messages in the queue on the disk as much as possible to reduce memory usage. | String ("lazy") |
Queues [Quorum] | Max in memory length | Maximum number of unacknowledged messages each consumer is allowed to consume before confirmation. | Number |
| Max in memory bytes | Maximum total memory bytes allowed in the queue. When the total memory bytes occupied by messages in the queue reach this limit, RabbitMQ will attempt to write the messages exceeding the limit to the disk to reduce memory usage. Note that this setting may not apply to queues with lazy mode enabled, because in the lazy mode, RabbitMQ stores messages to the disk as much as possible by default. | Number |
| Delivery limit | Maximum number of unacknowledged messages each consumer is allowed to consume before confirmation. | Number |
Exchanges | Alternate exchange | Secondary exchange. When a message cannot be routed to any queue (for example, there is no matching Routing Key or queue), it will be sent to the specified secondary exchange. | String |
4. Click Complete to complete the policy creation. You can see the created policy in the policy list.
Editing a Policy
1. In the policy list, click Edit in the Operation column of the target policy.
2. In the pop-up window, edit the policy information.
3. Click Complete to complete the modification.
Deleting a Policy
1. In the policy list, locate the target policy and click Delete in the Operation column.
2. In the pop-up dialog box, click Delete to complete the deletion.
Bantuan dan Dukungan
Apakah halaman ini membantu?
Anda juga dapat Menghubungi Penjualan atau Mengirimkan Tiket untuk meminta bantuan.
masukan