allthingssecurity opened a new pull request, #29293: URL: https://github.com/apache/camel/pull/29293
# Description [CAMEL-25961](https://issues.apache.org/jira/browse/CAMEL-25961) Follow-up of the reviews of #28262 (CAMEL-25841) and #28263 (CAMEL-25842). The consumers and producers of an account share one connection, and `XmppEndpoint.reconnect` connects and logs it in again under the account's lock. Two producer gaps were left: - `XmppPrivateChatProducer` and `XmppGroupChatProducer` reconnected only when the connection was not connected. A send that came while another user of the account, or Smack's `ReconnectionManager`, had connected it again but not logged it in yet went out before the login, and the server did not deliver it. They now call `endpoint.reconnect` before each send, as `XmppDirectProducer` and `XmppPubSubProducer` already do (it only connects and logs in when needed). - `XmppGroupChatProducer` did not enter its room again after the connection was lost, so the server dropped its messages to the room. It now re-enters the room before the next send after the connection logged in again (a `ConnectionListener` `authenticated` with `resumed=false`, as the consumer does since CAMEL-25842), and tries again at the next message if that fails; a first join that fails when the producer starts is tried again at the next message too (before, its messages went to a room it was not in). Smack still considers the old session joined, so `join` first sends a leave and waits for its answer (up to the reply timeout, 5 s by default, with a WARNING from Smack) before it enters; the consumer does the same. Known limitation: Smack keeps one `MultiUserChat` per connection and room, so a consumer and a group chat producer of the same account and room share it, and each re-enters the room after a reconnect: the second one leaves and enters again, so for a moment the consumer can miss room messages and a send can be dropped, once per reconnect. Avoiding that needs state shared by all users of the room (the session it was entered on); not done here. I would track it, with the consumer-monitor bullet below, in a follow-up JIRA. `jxmpp-version` is now 1.0.3: smack 4.4.x asks for jxmpp in the range `[1.0.0,1.0.999]`, so jxmpp-core and jxmpp-jid already resolved to 1.0.3 while jxmpp-util-cache was 1.1.0 (Claus's note on #28263), with a dependabot ignore for `org.jxmpp:*` 1.1 and later, as for `com.ibm.cloud:sdk-core`. Not changed, so this PR does not cover that bullet of the JIRA: the consumer's connection monitor keeps its own connect and login, not under the account's lock. Smack's `connect` and `login` are synchronized and the monitor already handles `AlreadyConnectedException`/`AlreadyLoggedInException`, so it is safe next to the producers; moving it is a refactoring that the producer fixes do not need, and `XmppConsumerConnectionRaceTest` pins the monitor's own login path. The direct and pubsub producers already reconnect before each send on main. Tests (`XmppProducerReconnectTest`, the in-JVM `FakeXmppServer`, no real server): - A private chat producer sends on a connection that another user connected again without logging it in: delivered. - A group chat producer sends to its room after the connection was lost, and after another user logged the connection in again: delivered, and the producer is an occupant again. - `FakeXmppServer` now takes a groupchat message only from an occupant of the room, and answers the presence with which an occupant leaves, as a real server does (the second makes stopping a group chat route quick in the tests). - All 3 fail against main code; with the change 20x: 60/60. All camel-xmpp test classes (offline): 29 run, 0 failures, 5 skipped (container tests). # 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-25961](https://issues.apache.org/jira/browse/CAMEL-25961). # 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-xmpp and the modules it depends on, including the formatter and import-sort plugins, and ran its unit tests. 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]
