- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
Since you are using MQTT 5 and the AWS IoT SDK, here are the key things to check regarding persistent sessions:
-
When creating the MQTT client connections, make sure to set the
Clean Start
property to0
in the client configuration. This ensures persistent sessions are used. See https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-persistent-sessions for more details. -
Also set the
Session Expiry interval
property to a non-zero value (for example 3600 seconds) when creating the clients. This controls how long the session state will be maintained after a disconnect. -
The AWS IoT SDK handles reconnect logic automatically in most languages. But confirm reconnect is enabled and the retry strategy if needed.
-
Do you want to use shared subscriptions? Shared Subscriptions allow multiple clients to share a subscription to a topic and only one client will receive messages published to that topic using a random distribution. Shared Subscriptions can effectively load balance MQTT messages across a number of subscribers. See https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt5-shared-subscription for more details
-
Monitor the persistent session metrics in CloudWatch to validate sessions are resumed properly after disconnects/reconnects.
I guess you are looking for a combination of persistent sessions and shared subscriptions, but let me know if you have any other specific configuration details to discuss or need clarification on using persistent sessions with the AWS IoT SDK.
let say I send a message to MQTT broker after instance A is down, all messages that I sent after instance A is down should be routed to instance B right. However, instance B is not receiving all the messages that sent after instance A is down
Is this just while the keep alive is timing out, or the problem persists even after the keep alive expires?
After adding the following configuration, the issue not happen again:
connectProperties.withSessionExpiryIntervalSeconds(60l); builder.withPingTimeoutMs(30000l); builder.withSessionBehavior(ClientSessionBehavior.REJOIN_ALWAYS);
May i know what is the different between ClientSessionBehavior.REJOIN_ALWAYS and ClientSessionBehavior.REJOIN_POST_SUCCESS? I try to understand by reading the comment but still couldn't figure out the differences. Should I use ClientSessionBehavior.REJOIN_ALWAYS or ClientSessionBehavior.REJOIN_POST_SUCCESS for persistent session?
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 2 Jahren
- Wie veröffentliche ich MQTT-Nachrichten von meinem Gerät auf AWS IoT Core, wenn ich Python verwende?AWS OFFICIALAktualisiert vor 3 Jahren
I am new to MQTT and AWS IOT core, may I know why enabling the persistent session able to solve the issue where last instance not able to receive all messages when the other instances were shut down?
When all other instances were shut down and left the last instance running, this last instance should receive all the messages from MQTT server right?
My guess here is, you want a group of nodes to process messages with QoS 1 (at least once). If message 1 was consumed by instance A, but the instance fails before acknowledging the message, instance B won't see the message again without a persistent session. A persistent session will keep any unacknowledged message, so if you are using shared subscription, after instance A fails, if instance B is in the same consumer group, it will receive the unacknowledged message 1 back again.
let say I send a message to MQTT broker after instance A is down, all messages that I sent after instance A is down should be routed to instance B right? However, instance B is not receiving all the messages that sent after instance A is down