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 subversion and git services (Jira)" <ji...@apache.org> on 2026/10/07 21:31:00 UTC
[jira] [Commented] (ARTEMIS-6292) Duplicate MQTT packet ID correlation keys
[ https://issues.apache.org/jira/browse/ARTEMIS-6292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18124745#comment-18124745 ]
ASF subversion and git services commented on ARTEMIS-6292:
----------------------------------------------------------
Commit c15afaeeb3bcec9121f6093fa581c3c83e3e2c2e in artemis's branch refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=artemis.git;h=c15afaeeb3 ]
ARTEMIS-6292 prevent duplicate MQTT packet ID correlation keys
The packet ID correlation key was mistakenly including the address to
which the message was sent rather than the queue from which the message
was consumed. This resulted in duplicate keys.
> Duplicate MQTT packet ID correlation keys
> -----------------------------------------
>
> Key: ARTEMIS-6292
> URL: https://issues.apache.org/jira/browse/ARTEMIS-6292
> Project: Artemis
> Issue Type: Bug
> Components: MQTT
> Reporter: Justin Bertram
> Assignee: Justin Bertram
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a MQTT client holds overlapping subscriptions, for example one on {{foo/bar}} and another on {{foo/#}}, a single published message is delivered to that client once per matching subscription. Each of those deliveries is a separate in-flight message and needs its own MQTT packet ID.
> For QoS 1 and QoS 2 the broker persists a packet ID correlation record to map the delivered message to the packet ID it assigned, so that a redelivery after a reconnect or a broker restart reuses the packet ID the client was originally given, as the specification requires. The key for that mapping can be duplicated when subscriptions overlap so every one of those deliveries computes the same identifier and they overwrite one another. Only the most recently stored delivery ends up with a mapping. Later when a client attempts to complete the QoS flow the broker will attempt to remove a packet ID correlation that doesn't actually exist and will log something like:
> {noformat}
> [Thread-0 (activemq-io-localhost)] 02:53:09,929 ERROR [org.apache.activemq.artemis.core.journal.impl.JournalImpl] Exception during appendCommitRecord:
> java.lang.IllegalStateException: Cannot find tx with id 76
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.lambda$appendCommitRecord$13(JournalImpl.java:1498)
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:59)
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:32)
> at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:69)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:120){noformat}
--
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