Is there any solution for MQTT QoS 2 message pulish connection drop issue?

[tsigcn]

I have met a connection droped issue when publish QoS 2 message to RabbitMQ.

The same as the following:
rabbitmq/rabbitmq-mqtt#155

Is there any solution to downgrade QoS2 to QoS1 when publish MQTT messages?

Any advice will be appreciated.

[michaelklishin]

@tsigcn QoS 2 is not supported by RabbitMQ. Such messages are treated as QoS 1 ones.

We cannot comment on "dropped connections" without an executable way to reproduce. We do not guess in this community.

[tsigcn]

RabbitMQ version is 3.13.4 and log as following:

2024-07-26 13:59:47.856348+00:00 [info] <0.129812.0> Accepted MQTT connection 20.2.216.247:52336 -> 10.2.0.4:1883 for client ID MQTT_FX_Client
2024-07-26 14:00:22.635367+00:00 [info] <0.129812.0> MQTT connection <<"20.2.216.247:52336 -> 10.2.0.4:1883">> will terminate because peer closed TCP connection
2024-07-26 14:01:55.247447+00:00 [info] <0.129824.0> Accepted MQTT connection 20.2.216.247:52367 -> 10.2.0.4:1883 for client ID t9FJMWdGS-nJ22zXRCdYXg
2024-07-26 14:01:55.249872+00:00 [info] <0.129824.0> MQTT connection <<"20.2.216.247:52367 -> 10.2.0.4:1883">> will terminate because peer closed TCP connection

[tsigcn]

@michaelklishin I think this is caused by the client has received PUBACK instead of PUBREC.

As mentioned before:

MQTT Publishes at QOS2 causes a connection failure for the publisher.

[michaelklishin]

That issue is from 2017. The MQTT plugin in 3.13 is very different.

[michaelklishin]

@ansd would know if this is an expected behavior but I can imagine that some tools would not handle a QoS downgrade gracefully. Many clients do, though, we have a good decade of evidence.

[michaelklishin]

I suspect that the answer to the question here is "no, there are no workarounds other than using QoS 1 which is a perfectly safe option in practice for an absolute majority of scenarios". Again, as more than a decade of evidence with several other protocols that use publisher confirms or its variation under a different name.

[michaelklishin]

I can imagine that some tools would not handle a QoS downgrade gracefully. Many clients do, though, we have a good decade of evidence.

I suspect that the answer to the question here is "no, there are no workarounds other than using QoS 1 which is a perfectly safe option in practice for an absolute majority of scenarios". Again, as more than a decade of evidence with several other protocols that use publisher confirms or its variation under a different name.

[ansd]

QoS 2 is unsupported in RabbitMQ, see https://www.rabbitmq.com/docs/mqtt#limitations

When a client sends a PUBLISH packet with QoS level 2, RabbitMQ will

• downgrade to QoS 1 in MQTT 3.1 and 3.1.1
• close the connection in MQTT 5.0.

Note that RabbitMQ implements the MQTT 5.0 behaviour according to the MQTT 5.0 spec:

If the Server included a Maximum QoS in its CONNACK response to a Client and it receives a PUBLISH packet with a QoS greater than this, then it uses DISCONNECT with Reason Code 0x9B (QoS not supported) as described in section 4.13 Handling errors.

[michaelklishin]

We will not make any promises as to when or if QoS 2 may land in RabbitMQ. Like I said, QoS 1 is perfectly sufficient as far as data safety goes. QoS 2 does not deliver any meaningful safety improvements but takes months of effort to implement for a small team like ours.

Other protocols RabbitMQ supports do not have a direct QoS 2 equivalent and their users are perfectly fine because they do provide a confirmation mechanism not meaningfully different from QoS 1 in MQTT.

[tsigcn]

@michaelklishin Got it for information of earlier versions.
Is there a RabbitMQ roadmap for MQTT QoS 2 support or not planned?

I think there are many scenes that clients send MQTT QoS 2 messages and cannot be changed to QoS 1 easily.
For example, our scenes have million of clients that cannot be changed to send QoS 1 message easily or need a long period.
Downgrade to QoS 1 is a good idea but it seems cannot be implement because the client got error and will keep retry.

Thanks for your patience.

[lukebakken]

We will not make any promises as to when or if QoS 2 may land in RabbitMQ

@tsigcn - how is that statement not clear with regard to QoS 2? It is not planned, nor on any roadmap.

[tsigcn]

@michaelklishin @lukebakken
It is clear with statement regard to QoS 2.
Your reply is faster than my post. :)

I think there is no better solution for my scenes at this time, and I will try to make clients send QoS 1 messages.
Thanks and regards.

[michaelklishin]

It may be added one day for cases such as this one but I though I have made it very clear that this is not a trivial time investment for a small team like ours, and we absolutely cannot make any public promises.

[lukebakken]

@tsigcn as explained here, RabbitMQ follows the MQTT 5.0 spec when QoS 2 is requested. If you would like to see RabbitMQ's behavior changed (to support a downgrade to QoS 1, for instance), you could implement it yourself, or you could contact Broadcom to become a paying RabbitMQ user, and make an official feature request.