eclipse-paho / eclipse-paho/paho.mqtt.java
setManualAcks in QoS 2
- Dominant language
- Java
- Stars
- 2.3k
- Forks
- 919
- PR merge metrics
- No merged PRs in 30d
Description
Please fill out the form below before submitting, thank you!
- [x ] Bug exists Release Version 1.2.5 ( Master Branch)
- [x ] Bug exists in MQTTv3 Client on Snapshot Version 1.2.6-SNAPSHOT (Develop Branch)
- [x ] Bug exists in MQTTv5 Client on Snapshot Version 1.2.6-SNAPSHOT (Develop Branch)
If this is a bug regarding the Android Service, please raise the bug here instead: https://github.com/eclipse/paho.mqtt.android/issues/new
The setManualAcks function is not implemented for QoS 2 messages.
The implementation for QoS 1 messages is fine. The PUBACK reply message is delayed until the client calls the messageArrivedComplete function. This somehow allows the client to commit the processing of the message. If anything fails during the processing, then the standard recovery of MQTT will deliver the QoS 1 message again.
The implementation for QoS 2 messages is incomplete, and I believe erroneous.
- when the client receives a QoS 2 PUBLISH, it immediately sends the PUBREC reply message (ClientState.notifyReceivedMsg, line 1226)
- when it receives the PUBREL, it immediately sends the PUBCOMP (ClientState.handleInboundPubRel, line 1151)
- the messageArrivedComplete function sends a duplicate PUBCOMP (CommsCallback.messageArrivedComplete, line 502)
I believe that the manualAcks option should work for QoS 2 messages exactly as for QoS 1 messages. The PUBREC message (and not the PUBCOMP) should be delayed until the client calls the messageArrivedComplete function. This would allow the same commit like feature which is particularly useful in QoS 2. If anything fails during the processing, then the standard recovery of MQTT will deliver the QoS 2 message again. The function should not be fixed delaying the PUBCOMP message, as a specific recovery mechanism should then be implemented.
Contributor guide
Assessment
This issue has not been assessed yet.