allthingssecurity opened a new pull request, #29581: URL: https://github.com/apache/camel/pull/29581
# Description [CAMEL-26800](https://issues.apache.org/jira/browse/CAMEL-26800) `MasterConsumer.doStop` gave up the leadership too early: - **The leadership was given up before the delegated consumer stopped.** `doStop` removed the listener and released the cluster view, then stopped the delegated consumer. On each graceful stop of the leader another node could take the leadership and start consuming while this node was still stopping its consumer: two active consumers in the cluster, which the `master` component is there to prevent. - **The route was stopped before the delegated consumer.** `doStop` called `super.doStop()` first, which stops the processor of the route, so a delegated consumer that routes its remaining messages while it stops (as JMS does) sent them into a stopped route, where they failed. - **A failure to release the view left the delegated consumer running.** No try/finally: when `releaseView` threw (the file lock cluster service when its data storage stalls), the delegated consumer was not stopped. Change: `doStop` cancels a pending start (as before), then stops the delegated consumer (the field is cleared first, so a failed stop does not leave it set and block the next leadership), then the processor of the route (`super.doStop()`), and removes the listener and releases the view in `finally` blocks, still without holding the leadership lock (the lock order note is kept). A leadership event that comes while the delegate stops is ignored, as the consumer is stopping (as before). Upgrade guide: a 4.24 entry, as the hand-over on a graceful stop now comes after the delegated consumer stopped. The shutdown strategy stops a `master:` consumer before it waits for the exchanges in flight, so those exchanges are still covered only when the delegated consumer waits for them in its stop (as JMS does). Not in this PR (follow-up, needs a decision on who owns the start and stop of the route processor): a start of the delegated consumer that ignores the interrupt of a cancel can complete after the master consumer was stopped and started again (or the leadership lost and taken again), and its consumer is then published next to the one of the current lifecycle. Dropping it with a stop would also stop the processor that the delegated consumers share. Tests, in `MasterConsumerLeadershipTest` (in-JVM test cluster view and probe endpoint, as the existing tests): - `testDelegateIsStoppedBeforeTheLeadershipIsGivenUp`: while the delegated consumer stops, the view must still be held, and a message it routes then must reach the route (`mock:result`); the view is released afterwards; - `testDelegateIsStoppedWhenReleasingTheViewFails`: a cluster service whose `releaseView` throws: the delegated consumer must still be stopped (and the view released). On main both fail (view released and route stopped before the delegate stop; delegate not stopped); with the view released last but the route still stopped first, the message routed while the delegate stops fails. With the change the camel-master tests pass (34, 0 failures, with the file lock failover tests of the module), and `MasterConsumerLeadershipTest` (12 tests) passes 240/240 over 20 runs in one JVM. Found with Specula (TLA+ model checked against traces of the real code) and code review, and confirmed with the tests 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-26800](https://issues.apache.org/jira/browse/CAMEL-26800). # 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-master with the formatter and import-sort plugins and ran the camel-master 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]
