tencent cloud

TDMQ for MQTT

Release Notes and Announcements
Release Notes
Product Introduction
TDMQ Product Series Introduction and Selection
What Is TDMQ for MQTT
Scenarios
Technical Architecture
Product series
MQTT Protocol Compatibility Notes
Comparison with Apache
High Availability
Product Constraints and Usage Quota
Basic Concepts
Supported Regions
Billing
Billing Overview
Renewal Instructions
Viewing Consumption Details
Overdue Payment Instructions
Refund
Getting Started
Guide for Getting Started
Preparations
Public Network Access
VPC Network Access
User Guide
Usage Process Guide
Configuring Account Permission
Creating a Cluster
Managing Topic
Connecting to the Cluster
Querying Messages
Managing Client
Managing a Cluster
Viewing Monitoring Metrics and Configuring Alarm Policies
Data Integration
Integrating Data Into SCF
Integrating Data Into CKafka
Integrating Data into RocketMQ
Development Guide
MQTT 5 Advanced Features
Data Plane HTTP API Description
Quota and Flow Control Mechanism Description
Configuring a Custom Domain Name
Configuring SQL Filtering
Configuring Point-to-Point Subscription
MQTT over QUIC
Managing Client Subscription
Message Enhancement Rule
Use Cases
Must-Knows for MQTT Client Development
Observability
Topic and Wildcard Subscriptions
​​API Reference
History
Introduction
API Category
Making API Requests
Cluster APIs
Topic APIs
Authorization Policy APIs
User APIs
Client APIs
Message Enhancement Rule APIs
Message APIs
Data Types
Error Codes
SDK Reference
Access Point Format
Java SDK
C SDK
Javascript/Node.JS/Mini Program
Go SDK
iOS SDK
JavaScript SDK
Dart SDK
Python SDK
.NET
Security and Compliance
Permission Management
FAQs
Related Agreement
Privacy Policy
Data Privacy And Security Agreement
TDMQ for MQTT Service Level Agreement
Contact Us
DocumentationTDMQ for MQTTUse CasesMust-Knows for MQTT Client Development

Must-Knows for MQTT Client Development

PDF
Focus Mode
Font Size
Last updated: 2026-04-01 16:37:51

Configuring Auto Reconnection for Clients

Whether accessing the MQTT cluster through the public network or private network, it is normal to see transport layer disconnection due to mobile device handover between base stations, network jitter, server version releases, and so on. Therefore, auto reconnection after disconnection and a reasonable backoff strategy need to be set for MQTT Clients.
You need to setconnection timeout, auto reconnection, minimum reconnection interval, maximum reconnection interval in Connect Options.
Java
C
public class MqttConnectionOptions {
...
// Automatic Reconnect
private boolean automaticReconnect = false;
// Time to wait before first automatic reconnection attempt in seconds.
private int automaticReconnectMinDelay = 1;
// Max time to wait for automatic reconnection attempts in seconds.
private int automaticReconnectMaxDelay = 120;
// Connection timeout in seconds
private int connectionTimeout = 30;
private int maxReconnectDelay = 128000;
...
}
struct MQTTAsync_connectOptions {
...
/**
* The time interval in seconds to allow a connect to complete.
*/
int connectTimeout;
/**
* Reconnect automatically in the case of a connection being lost. 0=false, 1=true
*/
int automaticReconnect;
/**
* The minimum automatic reconnect retry interval in seconds. Doubled on each failed retry.
*/
int minRetryInterval;
/**
* The maximum automatic reconnect retry interval in seconds. The doubling stops here on failed retries.
*/
int maxRetryInterval;
};

Paho SDK CleanSession=True or CleanStart=True Subscription

Paho SDK Subscriber Client: If the session is configured with CleanSession = True or CleanStart = True, the SDK does not automatically resubscribe after auto reconnection. Resubscription needs to be handled in the callback. See Issue 221.

Take Java callback as an example:
try (MqttClient client = new MqttClient(serverUri, clientId, new MemoryPersistence())) {
MqttConnectOptions options = new MqttConnectOptions();
options.setCleanSession(true);
...
client.setCallback(new MqttCallbackExtended() {
@Override
public void connectComplete(boolean reconnect, String serverURI) {
...
try {
// must resubscribe
client.subscribe(topicFilter, qos);
} catch (MqttException e) {
e.printStackTrace();
}
}
...
});
client.connect(options);
}

QoS Downgrade

When the MQTT server delivers messages to subscribers, it does not always deliver according to the QoS specified in the subscription expression. Instead, it uses the minimum value among publish message QoS, maximum QoS supported by the server, and subscription QoS.
Assuming the publish message i uses QoS 1, the maximum QoS supported by the server is QoS 2, and the subscription QoS is QoS 2, the message is delivered with QoS 1.



Help and Support

Was this page helpful?

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

Feedback