tencent cloud

TDMQ for RocketMQ

Release Notes and Announcements
Release Notes
Announcements
Product Introduction
Introduction and Selection of the TDMQ Product Series
What Is TDMQ for RocketMQ
Strengths
Scenarios
Product Series
Comparison with Open-Source RocketMQ
High Availability
Quotas and Limits
Supported Regions
Basic Concepts
Billing
Billing Overview
Pricing
Billing Examples
Pay-as-you-go Switch to Monthly Subscription (5.x)
Renewal
Viewing Consumption Details
Refund
Overdue Payments
Getting Started
Getting Started Guide
Preparations
Step 1: Creating TDMQ for RocketMQ Resources
Step 2: Using the SDK to Send and Receive Messages (Recommended)
Step 2: Running the TDMQ for RocketMQ Client (Optional)
Step 3: Querying Messages
Step 4: Deleting Resources
User Guide
Usage Process Guide
Configuring Account Permissions
Creating the Cluster
Configuring the Namespace
Configuring the Topic
Configuring the Group
Connecting to the Cluster
Managing Messages
Managing the Cluster
Viewing Monitoring Data and Configuring Alarms
Cross-Cluster Message Replication
Use Cases
Naming Conventions for Common Concepts of TDMQ for RocketMQ
RocketMQ Client Use Cases
RocketMQ Performance Load Testing and Capacity Assessment
Access over HTTP
Client Risk Descriptions and Update Guide
Migration Guide for TencentCloud API Operations Related to RocketMQ 4.x Cluster Roles
Migration Guide
Disruptive Migration
Seamless Migration
Developer Guide
Message Types
Message Filtering
Message Retries
POP Consumption Mode (5.x)
Clustering Consumption and Broadcasting Consumption
Subscription Relationship Consistency
Traffic Throttling
​​API Reference(5.x)
History
API Category
Making API Requests
Topic APIs
Consumer Group APIs
Message APIs
Role Authentication APIs
Hitless Migration APIs
Cloud Migration APIs
Cluster APIs
Data Types
Error Codes
​​API Reference(4.x)
SDK Reference
SDK Overview
5.x SDK
4.x SDK
Security and Compliance
Permission Management
CloudAudit
Deletion Protection
FAQs
4.x Instance FAQs
Agreements
TDMQ for RocketMQ Service Level Agreement
Contact Us

Message Retries

PDF
Focus Mode
Font Size
Last updated: 2026-01-23 17:52:23
This document mainly introduces the message retry mechanisms and their usage in TDMQ for RocketMQ.

Feature Introduction

When a message is consumed by a consumer for the first time but does not receive a normal acknowledgment, or when the user explicitly requests the server to redeliver the message, TDMQ for RocketMQ will automatically redeliver the message through the consumption retry mechanism until the message is successfully consumed. If the message still fails to be consumed after a certain number of retries, the retry process stops, and the message is delivered to a dead letter queue.
When messages enter the dead letter queue, it indicates that TDMQ for RocketMQ no longer automatically processes the messages. At this point, manual intervention is generally required to handle these messages. You can write a dedicated client to subscribe to the dead letter topic to process such messages.
Note:
The broker automatically retries only in the clustering consumption mode. No retry occurs in the broadcasting consumption mode.
The following three scenarios are treated as consumption failures and will trigger a retry:
The consumer returns ConsumeResult.FAILURE.
The consumer returns null.
The consumer explicitly or implicitly throws an exception.

Number of Retries

When a message needs to be retried, TDMQ for RocketMQ uses the configured messageDelayLevel parameter to define 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
Since the first delayLevel in the SDK starts at 3, the relationship between the number of retries and retry intervals is as follows:
Retry Attempt
Time Interval Since Last Retry
Retry Attempt
Time Interval Since Last Retry
1
10 seconds
9
7 minutes
2
30 seconds
10
8 minutes
3
1 minute
11
9 minutes
4
2 minutes
12
10 minutes
5
3 minutes
13
20 minutes
6
4 minutes
14
30 minutes
7
5 minutes
15
1 hour
8
6 minutes
16
2 hours

Usage Methods

5.x SDK
4.x SDK
No special handling is required. The 5.0 SDK follows the rules described above.
If you need to adjust the number of retries, you can set the following parameters for the consumer.
pushConsumer.setMaxReconsumeTimes(3);


Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback