You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@artemis.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2026/08/13 16:59:00 UTC
[jira] [Work logged] (ARTEMIS-6189) QoS 1 & 2 message handling is not resilient
[ https://issues.apache.org/jira/browse/ARTEMIS-6189?focusedWorklogId=1035656&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1035656 ]
ASF GitHub Bot logged work on ARTEMIS-6189:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 13/Aug/26 16:58
Start Date: 13/Aug/26 16:58
Worklog Time Spent: 10m
Work Description: jbertram opened a new pull request, #6613:
URL: https://github.com/apache/artemis/pull/6613
This PR implements MQTT QoS 1 and QoS 2 resiliency so that in-flight message flows survive broker restarts/crashes and client reconnects.
See [the Jira](https://issues.apache.org/jira/browse/ARTEMIS-6189) for details about exactly what isn't working.
See the individual commit messages for an overview of what's been changed.
I know this is big, but this was a complex task that required refactoring many core pieces of the MQTT implementation. It expanded a lot as I was working through it. Claude helped along the way.
The full test-suite is being run now, but I wanted to get it out for review sooner than later.
Issue Time Tracking
-------------------
Worklog Id: (was: 1035656)
Remaining Estimate: 0h
Time Spent: 10m
> QoS 1 & 2 message handling is not resilient
> -------------------------------------------
>
> Key: ARTEMIS-6189
> URL: https://issues.apache.org/jira/browse/ARTEMIS-6189
> Project: Artemis
> Issue Type: Bug
> Reporter: Justin Bertram
> Assignee: Justin Bertram
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> MQTT QoS 1 & 2 delivery relies on packet ID stability. In other words, when a message is redelivered, the broker must use the same packet ID it originally assigned so the client can correlate the redelivery with its prior state. The current implementation tracks packet ID assignments in memory, so all assignments are lost on broker restart. This means redelivered messages get new packet IDs, breaking the protocol contract.
> For inbound QoS 2 (client publishing to broker), duplicate detection is in-memory, so a broker restart can cause the same message to be persisted twice, violating exactly-once semantics.
> Testing confirms the following failures:
> h4. Packet ID not preserved on redelivery
> When the broker delivers a QoS 2 message to a subscriber but the flow is interrupted before the PUBREC is processed (either by a broker restart or a client disconnect), the broker assigns a new packet ID on redelivery instead of reusing the original one with the DUP flag set.
> The same packet ID preservation failure occurs for QoS 1 subscriber flows when the broker restarts or the client disconnects before the PUBACK is processed.
> h4. Publisher-side duplicate not detected after broker restart
> When a client publishes a QoS 2 message and the broker processes it internally but restarts before the PUBREC reaches the client, the client re-transmits the PUBLISH on reconnect. Because the inbound duplicate detection state is in-memory, the broker treats the retransmission as a new message, resulting in two copies in the queue instead of one.
> h4. Subscriber-side flow not resumed after interruption
> When the broker is partway through the QoS 2 flow (PUBREC received or PUBREL sent) and it is interrupted, the broker does not resume the flow on reconnect. It fails to re-send PUBREL, leaving the subscriber unable to complete the flow with PUBCOMP. This affects broker restart and client disconnect at both the post-PUBREC and post-PUBREL stages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@artemis.apache.org
For additional commands, e-mail: issues-help@artemis.apache.org