allthingssecurity opened a new pull request, #28462: URL: https://github.com/apache/camel/pull/28462
# Description [CAMEL-25944](https://issues.apache.org/jira/browse/CAMEL-25944) `PahoMqtt5Consumer.doStart` and `PahoConsumer.doStart` connected the client they created and only then set the callback. When the client connects to a session that the broker kept (camel-paho-mqtt5: `cleanStart=false` with a `sessionExpiryInterval`; camel-paho: `cleanSession=false`), the broker sends the messages it queued for the session right after CONNACK. Paho 1.2.5 drops a message that arrives while the client has no callback. I checked this with javap: `CommsCallback.messageArrived` queues a message only for an `mqttCallback` or a topic listener. Then: - MQTT 5: `ClientState` sends PUBREC for a QoS 2 PUBLISH whether or not it was delivered, and PUBCOMP on PUBREL, so a QoS 2 message (the default `qos`) is lost. A QoS 1 message stays unacknowledged until the next connect. - MQTT 3: a QoS 1 or QoS 2 message waits until the next connect, and is lost when the client is created again with the default memory persistence. Claus raised the ordering in the review of #28197 (CAMEL-25793). Changes: - Both consumers set the callback first and then connect the client they created. A client given with the `client` option is connected by the user, as before. - No option, docs or generated file change. - Merges cleanly with #28197 and with the open shared-client change (CAMEL-25851), where the connect then follows `PahoMqtt5ClientCallback.register` / `PahoClientCallback.register`. Tests: - New `PahoMqtt5ConsumerSessionMessagesTest` (QoS 2, `cleanStart=false`, `sessionExpiryInterval=3600`) and `PahoConsumerSessionMessagesTest` (QoS 1, `cleanSession=false`). A mocked client delivers a message from `connect()` to the callback set at that time and drops it when there is none, as Paho 1.2.5 does (comment in each test). Both fail on main: `mock://result Received message count. Expected: <1> but was: <0>`. - camel-paho-mqtt5 unit tests: 18 run, 0 failures. camel-paho unit tests: 29 run, 8 errors, the same 8 as on main. `PahoComponentTest` (7) and `PahoManualAcksTest` (1) cannot open a socket to the embedded Artemis broker in my sandbox (`SocketException: Invalid argument`); I did not run them anywhere else. Formatter and import sort ran. Built offline with `-Dasm-version=9.11` because the version of main was not in my local repository. - No integration test against a real broker. The ITs of both modules need a container, and I did not run them. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it): [CAMEL-25944](https://issues.apache.org/jira/browse/CAMEL-25944). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built camel-paho-mqtt5 and camel-paho and ran their unit tests, including the formatter and import-sort plugins. There are no generated file changes. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
