This topic describes the default server-side consumer retry policy for ApsaraMQ for RabbitMQ. This topic explains how messages are handled after a consumption failure to help you choose a suitable processing policy.
Consumer retry flow
The consumer retry mechanism improves system reliability and data consistency by automatically retrying to send or process messages when temporary failures occur.
-
Ready: Messages that are in a queue and waiting to be consumed.
-
Unack: Messages that a consumer has retrieved but not yet acknowledged. This means the message is received but not fully processed.
Retry policy properties
The consumer retry policy consists of two key properties: consumption timeout and maximum delivery attempts.
Consumption timeout
The consumption timeout is the maximum time allowed for a consumer to process a message. If a consumer does not process a message within this time, the message returns to the Ready state. Another consumer can then retrieve it. Setting a reasonable consumption timeout has the following advantages:
-
Avoid long suspensions: A reasonable consumption timeout prevents a consumer from being suspended for a long time while processing a message. This avoids message accumulation and improves overall system performance.
-
Ensure reliable message processing: If a consumer cannot process a message for a long time, ApsaraMQ for RabbitMQ redelivers the message to other consumers. This ensures that the message is processed promptly.
Maximum delivery attempts
The maximum delivery attempts is the maximum number of times the system tries to deliver a message to a consumer. Setting a reasonable number of maximum delivery attempts has the following advantages:
-
Avoid infinite retries: Setting a maximum number of delivery attempts prevents messages from being redelivered indefinitely. This avoids wasting system resources.
-
Failover: When the maximum number of delivery attempts is reached, the system can forward the message to a dead-letter queue. Developers can then analyze and process the message.
The x-delivery-limit property of a queue specifies the maximum number of redeliveries. The maximum number of delivery attempts equals x-delivery-limit + 1.
Instance retry policy parameter description
|
Instance type |
Serverless instances |
Subscription instances |
||
|
Shared |
Dedicated |
Enterprise Edition |
Platinum Edition |
|
|
Reserved + Elastic / Pay-by-accumulated usage |
Reserved + Elastic |
|||
|
Consumption timeout |
Maximum: 3 hours Default: 5 minutes |
Maximum: 12 hours Default: 30 minutes |
Maximum: 3 hours Default: 5 minutes |
Maximum: 12 hours Default: 30 minutes |
|
Maximum delivery attempts |
Maximum: 16 Default: 16 |
Maximum: 16 Default: 16 |
Maximum: 16 Default: 16 |
Maximum: 64 Default: 16 |
Modify the consumer retry policy
-
Log on to the ApsaraMQ for RabbitMQ console.
-
On the Overview page, in the Resource Distribution section, select a region and click the target instance.
-
Instance retry policy
-
On the Instance Details page, click the Retry Policy tab, and then click Edit.
-
In the Modify Retry Policy panel, set the values for Maximum Number of Deliveries and Consumption Timeout Period based on the value ranges described above.
-
-
Queue retry policy
-
In the navigation pane on the left, click Queue List, and then click the target queue.
-
On the Queue Details page, click the Retry Policy tab, and then click Edit.
-
In the Modify Retry Policy panel, set the values for Inherit Instance Configurations, Maximum Number of Deliveries, and Consumption Timeout Period based on the value ranges described above.
-
If a queue inherits the instance configuration, its retry policy is determined by the instance-level configuration. The queue's retry policy is updated whenever the instance-level configuration changes.
-
If a queue does not inherit the instance configuration, its retry policy is configured independently and overrides the instance-level configuration.
-
-
-
-
Click OK.