allthingssecurity opened a new pull request, #28708:
URL: https://github.com/apache/camel/pull/28708

   # Description
   
   [CAMEL-26305](https://issues.apache.org/jira/browse/CAMEL-26305)
   
   The producers and consumers of a `jgroups-raft:` endpoint share the 
`RaftHandle` the endpoint created (from `channelProperties` or the default 
configuration). When a route is removed, the core stops the endpoint of its 
consumer, also when other routes still use it, and `JGroupsRaftEndpoint.doStop` 
closed the handle's channel and its Raft log regardless of the producers and 
consumers still connected. The node left the Raft cluster and the producer 
route's `set` calls failed until the removed route was added again. As each 
endpoint creates its own handle with the endpoint's `raftId`, a node that 
changes the state machine and listens to role changes uses one uri for both, so 
removing the role-change route took the node out of the cluster. CAMEL-25883 
fixed this for the `raftHandle` of the component; the handle an endpoint 
creates itself was left as it was.
   
   Changes:
   - `JGroupsRaftEndpoint.doStop` closes its own handle (channel and log) only 
when no producer or consumer is connected; otherwise the last one that 
disconnects closes it once the endpoint is stopped. The count is now an `int` 
under a lock (as in camel-jgroups), so the check in `doStop` and a disconnect 
cannot interleave.
   - A connect is counted once it succeeded (as in camel-jgroups): a producer 
whose connect failed does not disconnect, so counting it before would keep the 
handle open for ever.
   - `doStart` keeps the endpoint's own handle while its channel is still open 
(with the change the handle can outlive a stop of the endpoint).
   - The handle of the component or a `raftHandle` bean is unchanged.
   - No option, generated file or upgrade guide change.
   - Backport candidates, for the maintainers to label if wanted (contributors 
cannot set `port/*` labels): camel-4.22.x and 4.18.x have the same `doStop` 
(read, not run).
   
   Tests:
   - New `JGroupsRaftRemoveRouteTest` (nodes A, B and C in the JVM with 
`raftABC.xml`; node A has a producer and a role-change consumer on the same 
uri):
     - `removeConsumerRouteKeepsTheHandleOfTheProducer` fails on main (3 runs: 
`the producer still uses the channel ==> expected: <true> but was: <false>`).
     - `removeBothRoutesClosesTheHandle` fails on main (3 runs, same message); 
with the change the channel stays connected after the consumer route is removed 
and is closed after the producer route is removed too.
     - `removeConsumerRouteThenAddItAgainKeepsTheHandle` fails on main (3 runs: 
`the re-added consumer uses the handle of the producer`): the re-added consumer 
must use the handle the producer is still connected to, as a new handle would 
leave the old one in the cluster after both routes stop.
   - camel-jgroups-raft: 22 tests, 0 failures. The formatter and import-sort 
plugins ran.
   
   How it was found: a code sweep for endpoints whose `doStop` releases 
something that other routes on the same uri still use, after a random 
lifecycle-sequence harness found the same kind of defect in camel-disruptor 
(CAMEL-26286).
   
   # 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-26305) 
filed for the change (usually before you start working on it): 
[CAMEL-26305](https://issues.apache.org/jira/browse/CAMEL-26305).
   
   # 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-jgroups-raft and ran its tests, including the formatter and 
import-sort plugins. 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]

Reply via email to