allthingssecurity opened a new pull request, #29582: URL: https://github.com/apache/camel/pull/29582
# Description [CAMEL-26801](https://issues.apache.org/jira/browse/CAMEL-26801) `ZooKeeperClusterView` kept the Curator client that `ZooKeeperClusterService` gave it when the view was created. When the service is stopped and started again (from JMX, for example), it closes its managed client (`doStop`) and creates a new one (`doStart`), then starts the views that are still in use. A view then created its `LeaderSelector` on the closed client, so the node no longer took part in the election: it never became the leader, also when all the other nodes went away, and the clustered routes and `master` consumers that use the view never ran on it again. A restart of the CamelContext does not help either: it stops and starts the same service, which keeps its views; only a restart of the application did. This is the ZooKeeper counterpart of CAMEL-25061 (file lock cluster service restart). Change: the view gets the client from the service when it starts (a supplier, `ZooKeeperClusterService::getOrCreateCurator`), instead of the client it was created with. The service creates its client before it starts the views, so a started view always uses the current one. A user-provided client (`configuration.getCuratorFramework()`, not managed by the service) is unchanged: it is not closed on stop, and the view gets the same one. Test: new `ZooKeeperClusterServiceRestartTest`, with a ZooKeeper server in the test JVM (`ZooKeeperServer` + `NIOServerCnxnFactory` from the ZooKeeper jar already on the test classpath, as `ZooKeeperConsumerSessionExpiryTest` does; no Docker and no new dependency). It is the first in-JVM test of the ZooKeeper cluster service (the existing cluster tests are `*IT` with the test-infra container). Two services on two CamelContexts: the first is the leader; the service of the second is stopped and started again; the first service stops: the second must become the leader. The view is the same on 4.18.x and 4.23.x (4.14.x differs slightly), so the change cherry-picks there if a backport is wanted. On main the test fails (the restarted service never becomes the leader). With the change the camel-zookeeper unit tests pass (26, 0 failures), and the new test passes 20/20 over 20 runs in one JVM. Found with Specula (TLA+ model checked against traces of the real code) and confirmed with the test above. # 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-26801](https://issues.apache.org/jira/browse/CAMEL-26801). # 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 the core modules and camel-zookeeper with the formatter and import-sort plugins and ran the camel-zookeeper 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]
