[grepjava]

MQTTRetainMessageManager.handleRetainedMessage looked up the topic's retain queue and created it when missing with createQueue(QueueConfiguration). Two connections publishing the first retained messages to a topic at the same time could both find no queue, and the second createQueue threw ActiveMQQueueExistsException (AMQ229019). The publish was rolled back and the client got no PUBACK: the message reached neither the subscribers nor the retain queue.

The queue is now created with ignoreIfExists, so a connection that loses the race uses the queue the other one created.

MQTTTest.testFirstRetainedMessagesPublishedAtOnce has 16 clients publish a retained QoS 1 message to a new topic at once, for 10 topics, and checks that every publish is acknowledged and a new subscriber gets one retained message. It fails without the fix.

https://issues.apache.org/jira/browse/ARTEMIS-6358

[jbertram]

I'm confused by the title referencing lost messages. Typically a "lost" message is one where the client has every confidence that the message was actually published successfully when, in fact, it wasn't. If a publisher gets no PUBACK then it can assume the corresponding PUBLISH was not successful so there is no "lost" message.

It seems that a commit message like "fix race when sending concurrent retained messages" would be more accurate.

[grepjava]

You're right, "lost" isn't accurate here — the client never gets a PUBACK for the failed publish, so on QoS 1 it just retries and the retained message lands. The real defect is the race itself: two connections publishing a retained message to the same new topic at once both see locateQueue return null and both call createQueue, and the loser gets an exception. I've retitled the PR and the commit to "Fix race when sending concurrent retained messages" and reworded the commit body accordingly. Thanks for the catch.

[jbertram]

Thanks, @grepjava!