The Artemis message broker is no longer part of the ActiveMQ project. It became its own top-level Apache project in November of last year [1]. Therefore, you should use Artemis' dev mailing list (i.e. [email protected]) [2].
Regarding the actual issues, they look legitimate. Please request a Jira account and once granted please file a Jira for each of the 3 issues. If possible, attach a minimal reproducer (i.e. your Python scripts). Lastly, you can test unreleased changes using a snapshot [3]. Justin [1] https://activemq.apache.org/news/artemis-tlp [2] https://artemis.apache.org/contact [3] https://repository.apache.org/content/repositories/snapshots/org/apache/artemis/apache-artemis/ On Mon, Sep 21, 2026 at 6:45 AM cf g <[email protected]> wrote: > Hello, > > Our team @AIS2Lab has been testing MQTT 5 conformance across broker > implementations, and we found > three behaviours in Apache Artemis 2.57.0 that we believe are specification > violations. Two of them > concern the Will Message and share a code path; the third is separate. > > We do not have an ASF Jira account. The Jira signup page suggests raising > things on the project > mailing list first, so we are doing that. If you confirm these are bugs we > are happy to request an > account and file them, or someone with an account is welcome to file them > directly. > > Every check below runs its arm and a control in the same execution against > the same broker, so a > silent result cannot be a blind spot in the test. Each was reproduced 3 out > of 3 runs with a fresh > Client Identifier and topic namespace, on a freshly started container. > > > 1. The Will Message is not published after DISCONNECT with Reason Code 0x04 > --------------------------------------------------------------------------- > > Section 3.14.2.1 defines Reason Code 0x04 as "Disconnect with Will > Message": the Client is > disconnecting and explicitly asks for the Will to be sent. Section 3.1.2.5 > allows the Will to be > discarded only on a DISCONNECT with Reason Code 0x00. > > abrupt close (TCP RST) : Will published after 0.0s <- correct, > and this is the control > DISCONNECT Reason Code 0x04 : Will NOT published > > The abrupt-close arm is the control. It runs in the same execution against > the same watcher and the > same topic, which is what shows the broker does publish Wills and that the > test can see them. > > > 2. A DISCONNECT with a reserved Reason Code is treated as a normal > disconnection > > -------------------------------------------------------------------------------- > > A client connects with a Will and then sends four bytes: e0 02 ff 00, a > DISCONNECT with Reason > Code 0xFF. That code is not in the table of section 3.14.2.1, so by section > 4.13 the packet is a > Malformed Packet and the Server is expected to close the connection with > DISCONNECT 0x81. > Section 3.1.2.5 again allows the Will to be deleted only on Reason Code > 0x00. > > --> DISCONNECT rc=0xff e0 02 ff 00 > <-- nothing; the server closes without sending DISCONNECT 0x81 > ... 10 seconds of silence on the Will topic ... > > So on either reading, whether the packet is rejected as malformed or > accepted as a DISCONNECT with > a non-zero Reason Code, the Will should still have been published. > > To be explicit, since this is easy to misread: this is not a normal > DISCONNECT 0x00. A > DISCONNECT 0x00 correctly discards the Will and we are not reporting that. > > We noticed ARTEMIS-6190, "MQTT Will message properties propagation", is > Resolved with fix version > 2.58.0. It touches Will handling, so it may or may not cover these two > cases. We could not check: > 2.57.0 is the newest released version, and there is no 2.58.0 image to test > against yet. If you > expect 6190 to cover them, we are glad to retest as soon as 2.58.0 ships > and report back. > > > 3. A Message Expiry Interval deletes a QoS 2 exchange that already passed > PUBREC > > -------------------------------------------------------------------------------- > > Section 3.3.2.3.3 applies the Message Expiry Interval to an Application > Message the Server is > holding. Once the receiver has answered PUBREC the delivery is under way > and what remains > outstanding is an acknowledgement, which section 4.4 [MQTT-4.4.0-1] > requires the Server to resend on > the resumed Session. Section 4.1 lists incomplete inbound QoS 2 exchanges > as Session State. > > Two identities, identical except for the Message Expiry Interval, in the > same run: subscribe QoS 2 > with Clean Start 0 and Session Expiry Interval 300, answer PUBREC, cut the > TCP connection, wait 12 > seconds, reconnect Clean Start 0. > > control, published with NO Message Expiry Interval : session_present=1 > PUBREL resent = True > arm, Message Expiry Interval = 5 : session_present=1 > PUBREL resent = False > > The control recovers, so this is not a general [MQTT-4.4.0-1] problem. The > expiry is deleting an > exchange that had already started. > > Note that ARTEMIS-6189, "QoS 1 & 2 message handling is not resilient", is > fixed in 2.56.0 and is > therefore already included in the version we tested. This is a different > path. > > > Environment > ----------- > > Apache Artemis 2.57.0, official image apache/artemis:2.57.0, > digest > sha256:c691a1fe64eeda556db8b550822caa6c50cd8088c70b38bc22c26cf2aa7312bb > ANONYMOUS_LOGIN=true, otherwise image defaults > Reached on the image's own MQTT acceptor, container port 1883 > <acceptor name="mqtt">tcp://0.0.0.0:1883?...;protocols=MQTT</acceptor> > not the multi-protocol "artemis" acceptor on 61616 > MQTT v5.0 over plain TCP, loopback only > Host: Ubuntu 22.04.5 LTS, kernel 5.15.0-191-generic, x86_64, Docker > Engine 29.4.3 > > > Reproducers > ----------- > > We have two standalone programs for these, one for the Will cases and one > for the QoS 2 case. They > are Python 3, standard library only, no MQTT client library, so every byte > they send is visible in > the source, and they print every frame in both directions. Each exits 1 > while the behaviour is > present and 0 once it is fixed, so they can be dropped into a regression > suite. > > They are about 300 lines each, so we have not pasted them into this email. > Say the word and we will > send them inline, attach them, or put them in a Jira issue, whichever you > prefer. > > Thanks for your time, > @AIS2Lab >
