- 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 message retry mechanisms and their usages in TDMQ for RocketMQ.
Feature Overview
When a message is consumed for the first time by a consumer and fails to get a normal response, or when it is requested by users to deliver again in the server, TDMQ for RocketMQ will automatically retry delivering this message 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. At this point, human intervention is generally required. You can write a dedicated client to subscribe to the dead letter queue to process such messages.
Note
The broker will automatically retry in the cluster consumption mode but not the broadcast consumption mode.
The following results are considered as consumption failure, and the message will be retried accordingly:
1. The consumer returns
ConsumeConcurrentlyStatus.RECONSUME_LATER.2. The consumer returns null.
3. The consumer actively/passively throws an exception.
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
If you need to adjust the number of retries by yourself, you can set the parameters of the consumer.
pushConsumer.setMaxReconsumeTimes(3);
Yes
No
Was this page helpful?