davsclaus opened a new pull request, #26862: URL: https://github.com/apache/camel/pull/26862
_Claude Code on behalf of Claus Ibsen (davsclaus)_ JIRA: https://issues.apache.org/jira/browse/CAMEL-25004 A review of the producer cache (`ServicePool`) and the stream caching strategy (`DefaultStreamCachingStrategy`) found the bugs below. Each fix has a test that fails without it. 1. **Evicting the producer of an endpoint in use stopped the endpoint.** When the producer of a singleton endpoint was evicted from a producer cache (for example the cache of toD with a small `cacheSize`), `ServicePool` also stopped the endpoint, and has done so since CAMEL-14594. It did that even when the routes used the endpoint, for example one a route consumes from. The endpoint was started again on next use, but stayed stopped in between. It is now only stopped when the routes don't use it: a dynamic endpoint (such as one created by toD) that no route consumes from. So dynamic endpoints still free their resources, which is what CAMEL-14594 was for. `ProducerCacheEvictEndpointInUseTest` covers both cases. 2. **The stream caching strategy accumulated its configuration when started again.** Each start added the threshold spool rules, the `allowClasses`/`denyClasses` given by name, and the core type converters again. They are now not duplicated: the threshold spool rules are removed on stop, the classes are added only once, and the converters are cleared first. 3. **`allowClasses`/`denyClasses` given both as classes and as names failed.** `setAllowClasses(Class...)` stores an immutable list, and starting then tried to add the classes given by name to it, which threw `UnsupportedOperationException`. 4. **The spool directory was not removed when spooling only by used heap memory.** It was only removed on stop when `spoolThreshold > 0`. When spooling was driven only by `spoolUsedHeapMemoryThreshold` or by custom spool rules, the directory was left behind. It is now removed whenever spooling to disk was in use. ### Not changed (left for follow-up) - **The strategy is not stopped again after a context restart.** The stream caching strategy is registered as an internal service of the CamelContext, and the internal services are cleared when the context stops. After a restart, the same strategy instance is used but no longer tracked, so it is not stopped again the next time the context stops, and its spool directory is then left behind. This needs a closer look at how lazily created internal services are re-registered on restart, so it is left for its own ticket. The tests here stop and start the strategy directly. ### Tests - New `ProducerCacheEvictEndpointInUseTest` and `StreamCachingStrategyRestartTest`. The in-use endpoint case and all three stream caching cases fail without the fix. - The full `core/camel-support` suite passes (125 tests), and the full `core/camel-core` suite passes: 7594 tests, 0 failures, 44 skipped. Three tests were flaky and passed on rerun. `FileMulticastDeleteTest` and `FileConsumerInterceptEmptyFileTest` also pass 5 out of 5 runs on both this branch and main, and `RestProducerUnresolvedPathWarnTest` is fixed by #26854. 🤖 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]
