allthingssecurity opened a new pull request, #28645: URL: https://github.com/apache/camel/pull/28645
# Description [CAMEL-26302](https://issues.apache.org/jira/browse/CAMEL-26302) When a route is removed, the core stops and shuts down the endpoint of its consumer, also when other routes still use it. For ehcache that released caches the other routes still hold: - `EhcacheEndpoint.doStop` released the endpoint's reference on its `EhcacheManager`. Without `cacheManager`, `cacheManagerConfiguration` or `configurationUri` the endpoint has its own cache manager, so that was the last reference and it closed the `CacheManager` with its caches. - `EhcacheEndpoint.doShutdown` shut the `EhcacheManager` down, which closes the caches it created without a configuration, also when the manager is shared by other endpoints (`cacheManager`, `cacheManagerConfiguration`, `configurationUri`). The producers of the other routes keep their `Cache`, so every action failed with `IllegalStateException: State is UNINITIALIZED`, also after the route was added again. Example: `from("ehcache:orders?configuration=#ordersConfig")` reacting to cache events and `to("ehcache:orders?configuration=#ordersConfig")` in other routes (they must use the same uri to share the cache, see CAMEL-26237); removing the event route (a reload, a route template removed) broke the producer routes. Changes: - `EhcacheProducer` and `EhcacheConsumer` hold a reference on the `EhcacheManager` while they are started (as the endpoints already do), so a cache manager is closed by the last of its users. - `EhcacheEndpoint.doShutdown` shuts the `EhcacheManager` down only when nothing uses it any more. - The last reference also closes the caches the manager created without a configuration. Before, only the shutdown of an endpoint closed them; an endpoint that was shut down with a removed route while other routes still used them is not shut down again, so without this they stayed open after the context stopped. - `EhcacheConsumer.doStop` releases its reference also when removing its cache event listener fails, and removes the listener only when it has a cache. Removing a route that never started (such as one with `autoStartup=false`) stops its consumer, which has no cache: on main its `doStop` failed with a `NullPointerException` (`this.cache` is null), so the route could not be removed (`RuntimeCamelException` from `removeRoute`). - `EhcacheManagerTest` counts the producers too: 4 references for two endpoints with their producers (was 2); after the context stop it is 0 and the cache manager is closed (a `cacheManager` from the registry stays open), as before. - No option, generated file or upgrade guide change. - Backport: camel-4.22.x, 4.18.x and 4.14.x have the same `doStop`/`doShutdown` (read, not run). Tests: - New `EhcacheRemoveRouteTest`: `removeEventRouteOfSameEndpoint`, `removeEventRouteOfSharedCacheManager` (a registry cache manager with a configured cache and one created on demand), `removeEventRouteThenAddItAgain` and `removeEventRouteThenStopClosesCacheCreatedOnDemand` (no cache manager option and no configuration, so the endpoint's own manager creates a user managed cache; it must be closed after the context stop) fail on main (3 runs, each with `IllegalStateException: State is UNINITIALIZED` on the first action after the removal) and pass with the change. Without the closing by the last reference, the fourth test fails with `expected: <UNINITIALIZED> but was: <AVAILABLE>`. - `removeEventRouteThatNeverStarted` (same class): a route with `autoStartup(false)` on the endpoint of a running route is removed, and the running route still gets its events. Without the null check it fails with `RuntimeCamelException: java.lang.NullPointerException: Cannot invoke "org.ehcache.Cache.getRuntimeConfiguration()" because "this.cache" is null` (as on main). - camel-ehcache: 78 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). Related: CAMEL-26237 (each endpoint uri without a cache manager option builds its own cache manager, and a consumer on a cache without configuration gets no events). Not changed here. # 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-26302) filed for the change (usually before you start working on it): [CAMEL-26302](https://issues.apache.org/jira/browse/CAMEL-26302). # 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-ehcache 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]
