allthingssecurity opened a new pull request, #28325: URL: https://github.com/apache/camel/pull/28325
# Description [CAMEL-25852](https://issues.apache.org/jira/browse/CAMEL-25852) The `channel` option of the JGroups component is given to every endpoint of the component, but each `JGroupsEndpoint` counted only its own producers and consumers: when those of one endpoint stopped, it disconnected the shared channel, and when the endpoint itself stopped (for example when its route was removed) it closed it. A route consuming from another endpoint of the same cluster (such as `jgroups:orders?enableViewMessages=true` next to a producer to `jgroups:orders`) then stayed started and received nothing more; after the close, for good, as a closed `JChannel` cannot be connected again. Changes: - `JGroupsComponent` counts the producers and consumers of a channel that the endpoints did not create (`connectSharedChannel` / `disconnectSharedChannel`) and disconnects it when the last of them stops. - `JGroupsEndpoint` closes only a channel it created. The channel of the component is closed when the component stops (before, by the first endpoint that stopped). A channel given to one endpoint on its URI (`channel=#myChannel`, bound to the endpoint by reflection) is not created by the endpoint either: it is counted the same way, and the component closes it when it stops (before, its endpoint closed it), so it is still closed when the CamelContext stops. A channel an endpoint creates itself (from `channelProperties` or the default) is handled as before. - `JGroupsProducer` and `JGroupsConsumer` disconnect only when they connected. Camel stops a service whose start failed (`BaseService.start` calls `stop()`), and a consumer without `acceptAllObjects`, a filter or a secured channel refuses to start before it connects: its stop took away a use it never added, and disconnected the shared channel under a running producer of another endpoint. A stopping consumer also removes the channel's receiver only when it is its own, so a consumer that failed to start no longer removes the receiver of a running consumer. No option changed; the component channel is still closed at shutdown, so no upgrade guide entry. Not changed: two consumers on one channel still replace each other's receiver (`setReceiver`) when they start, a separate limitation. camel-jgroups-raft has the same pattern for the `raftHandle` of its component (each `JGroupsRaftEndpoint` counts only its own producers and consumers, disconnects the handle's channel and closes the channel and the log when it stops); it is fixed separately in [CAMEL-25883](https://issues.apache.org/jira/browse/CAMEL-25883) rather than in this PR. Tests: - New `JGroupsComponentChannelEndpointsTest` (component channel, a producer route and a consumer route on two endpoints of the same cluster, messages sent by a separate channel): `stoppingTheProducerKeepsTheConsumerReceiving` and `removingTheProducerRouteKeepsTheConsumerReceiving` both fail without the change with `mock://received Received message count. Expected: <1> but was: <0>`, and pass with the change. - `stoppingTheCamelContextClosesTheChannels` (a third route on another cluster with `channel=#endpointChannel`) is a control for the close at shutdown: it passes on main, where the endpoints closed both channels, and checks that the change keeps that. Without the component closing the channels its endpoints were given, it fails with `expected: <true> but was: <false>` for the endpoint's channel. - `aConsumerThatFailsToStartKeepsTheChannelOfTheProducerConnected` (consumer route stopped, then a route `jgroups:<cluster>?enableViewMessages=true` added, which fails to start) fails without the connected flags with `the channel of the producer is still connected ==> expected: <true> but was: <false>`, and `aConsumerThatFailsToStartKeepsTheOtherConsumerReceiving` (the same failing route next to the running consumer) with `mock://received Received message count. Expected: <1> but was: <0>`. Both pass with the change. - camel-jgroups unit tests with the change: 31 run, 0 failures. How it was found: variant analysis of CAMEL-25849 and CAMEL-25850 (a resource that belongs to one owner kept where another owner finds and stops it), then the JUnit test. What was not run: the full root build. # 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-25852](https://issues.apache.org/jira/browse/CAMEL-25852). # 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 and tested camel-jgroups. No option changed. 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]
