/
Increased Queued Messages and Message Delivery Issues After Client Reconnection

Increased Queued Messages and Message Delivery Issues After Client Reconnection

 Problem

  • A client experiences a network glitch or TCP connection loss.

  • Upon reconnection, no messages are delivered to the client, and the broker shows an increased number of queued messages for the client.

  • Trace recordings typically show PINGREQ and PINGRESP packets, indicating that the connection is alive but message delivery is stalled.

Root cause:

This issue may occur due to one or more of the following reasons:

  • MQTT QoS 1/2 message flow might be stuck due to improper message state synchronization after reconnection.

  • The client is unable to properly acknowledge or resume in-flight messages post reconnect.

  • No client-side recovery mechanism is implemented when message delivery is stalled.

Workaround:

Restart the client modules/applications.

 Solution

To mitigate and prevent this issue, consider the following best practices:

1. Use QoS 1 Instead of QoS 2 (If Possible)

  • QoS 2 provides exactly-once delivery, but introduces more complexity in message state handling.

  • In many real-world scenarios, QoS 1 (at-least-once delivery) offers a more reliable and efficient alternative with fewer risks of getting stuck in message retransmission states.

  • Recommendation: If your application does not strictly require exactly-once delivery semantics, configure clients and publishers to use QoS 1.

2. Implement a Client-Side Reconnect Strategy

  • Ensure clients are configured to monitor incoming messages and reconnect proactively when delivery appears stalled.

  • This approach helps recover from silent failures or stuck sessions without relying on broker-side detection.

3. Verify MQTT Client Library Behavior

  • Ensure the MQTT client library in use supports robust session recovery after disconnects.

  • Some libraries may not handle in-flight QoS 2 messages well after reconnect unless specifically configured.

  • Consult your client library documentation for options related to:

    • Clean session vs persistent session handling.

    • Message re-delivery and acknowledgement after reconnect.

  • Always use the latest version of the Client library.

Additional Tips

  • Enable debug or trace logs on the client and broker to observe message flows during and after reconnections.

  • Use HiveMQ's Trace Recordings to identify stalled sessions or pending messages.

 

 Related articles