- Release Notes and Announcements
- Product Introduction
- Purchase Guide
- RocketMQ 5.x
- RocketMQ 4.x
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Development Guide
- SDK Documentation
- Migration to Cloud
- API Documentation
- FAQs
- TDMQ FOR ROCKETMQ SERVICE LEVEL AGREEMENT
- Contact Us
- Release Notes and Announcements
- Product Introduction
- Purchase Guide
- RocketMQ 5.x
- RocketMQ 4.x
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Development Guide
- SDK Documentation
- Migration to Cloud
- API Documentation
- FAQs
- TDMQ FOR ROCKETMQ SERVICE LEVEL AGREEMENT
- Contact Us
This document describes the mechanism of message retry and its usage in TDMQ for RocketMQ.
Feature Description
When a message is consumed for the first time by a consumer and does not receive a normal response, or when users request the server to deliver it again, TDMQ for RocketMQ will automatically attempt to deliver this message again through the message retry mechanism until it is consumed successfully. When the number of retries reaches the specified value but the message is still not consumed successfully, retry will stop, and the message will be delivered to the dead letter queue.
After the message enters the dead letter queue, TDMQ for RocketMQ can no longer process it automatically. In this situation, human intervention is generally required. You can write a dedicated client to subscribe to the dead letter queue to process such failed messages.
Note:
The broker will automatically retry in the cluster consumption mode but not the broadcasting consumption mode.
The following results are considered as consumption failure, and the message will be retried accordingly:
The consumer returns ConsumeResult.FAILURE.
The consumer returns null.
The consumer actively/passively throws an exception.
Maximum Number of Retries
When a message needs to be retried in TDMQ for RocketMQ, set the messageDelayLevel parameter as follows to configure the number of retries and retry intervals:
messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h
The number of retries and retry intervals have the following relationships:
Retry No. | Time Interval Since Last Retry | Retry No. | Time Interval Since Last Retry |
1 | 1 second | 10 | 6 minutes |
2 | 5 seconds | 11 | 7 minutes |
3 | 10 seconds | 12 | 8 minutes |
4 | 30 seconds | 13 | 9 minutes |
5 | 1 minute | 14 | 10 minutes |
6 | 2 minutes | 15 | 20 minutes |
7 | 3 minutes | 16 | 30 minutes |
8 | 4 minutes | 17 | 1 hour |
9 | 5 minutes | 18 | 2 hours |
Instructions
No special processing is required, the 5.0 SDK follows the preceding rules.
Yes
No
Was this page helpful?