MQTT Broker on AWS IoT Cloud constantly receiving the same message without stopping

0

We’re working with AWS Greengrass and are troubleshooting a strange behavior. Using the MQTT Test Client in the AWS Console, we’re observing that some messages from our Greengrass Core devices are being received repeatedly—sometimes with outdated timestamps (e.g., from the previous day). In certain cases, the MQTT Test Client continues to receive the same messages even after we've shut down the associated AWS Thing and Greengrass Core device, suggesting that something might be “stuck” in the cloud-side MQTT broker.

We're using QoS 1, but the volume and pattern of these duplicate messages seem inconsistent with normal QoS behavior. The AWS Things are not configured for persistent sessions, but we're uncertain about the session configuration used by the Greengrass Core.

Has anyone encountered similar behavior or have insights into what might cause this?

asked 11 days ago58 views
1 Answer
0

The behavior you're describing is unusual and not typical for AWS IoT Core or Greengrass MQTT communication. However, there are a few potential explanations and areas to investigate:

  1. Client ID conflicts: If multiple devices or connections are using the same MQTT client ID, it can cause unexpected behavior. When a new connection is established using a client ID that's already in use, the AWS IoT message broker drops the old connection to allow the new one. This could potentially lead to message duplication or persistence issues.

  2. MQTT bridge configuration: The Greengrass MQTT bridge component relays messages between client devices, local Greengrass publish/subscribe, and AWS IoT Core. It uses QoS 1 to publish and subscribe to AWS IoT Core, even when a client device uses QoS 0 locally. This could introduce some additional latency or potential for message duplication, but shouldn't cause the extreme behavior you're seeing.

  3. Persistent sessions: While you mentioned that AWS Things are not configured for persistent sessions, it's worth double-checking the Greengrass Core configuration. Persistent sessions can cause messages to be stored and retransmitted, which could explain some of the behavior you're seeing.

  4. Message retention: Check if any message retention policies are configured on the topics in question. Retained messages in MQTT can cause messages to persist even after the publishing client disconnects.

  5. Cloud-side caching or processing: There might be some unexpected caching or processing happening on the AWS IoT Core side that's causing messages to be stored and retransmitted.

To troubleshoot this issue:

  1. Ensure all devices and connections use unique client IDs.
  2. Review your MQTT bridge configuration in Greengrass.
  3. Double-check session persistence settings for both AWS Things and Greengrass Cores.
  4. Investigate any message retention policies on your topics.
  5. Monitor your device connections and disconnections carefully to see if there are any unexpected patterns.
  6. Consider implementing message sequencing or timestamps in your payloads to help track message order and identify duplicates.

If the issue persists after checking these areas, it would be advisable to contact AWS support for further investigation, as this behavior is not normal for the AWS IoT Core MQTT broker.
Sources
MQTT multiple subscribers to one topic not working | AWS re:Post
MQTT bridge - AWS IoT Greengrass

profile picture
answered 11 days ago
profile pictureAWS
EXPERT
reviewed 10 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions