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

   # Description
   
   [CAMEL-26477](https://issues.apache.org/jira/browse/CAMEL-26477), a possible 
correctness bug listed in 
[CAMEL-25132](https://issues.apache.org/jira/browse/CAMEL-25132).
   
   With `camel.threads.virtual.enabled=true`, `DefaultThreadPoolFactory` 
created the scheduled pool without `setRemoveOnCancelPolicy(true)`, which the 
platform thread path does set. A cancelled task therefore stayed in the queue 
until its delay expired.
   
   `MulticastProcessor` creates its timeout pool this way, and cancels the 
timeout task when a split or multicast with a `timeout` completes. That task 
refers to its `MulticastTask`, so its exchanges stay in memory for the whole 
timeout. The leak itself was not measured; the test shows that the cancelled 
task stays queued.
   
   ## Tests
   
   `ScheduledThreadPoolRemoveOnCancelTest` creates the pool as 
`MulticastProcessor` does, then schedules and cancels a task. It has no 
condition, so it covers whichever mode the JVM runs in. **The default build 
runs platform threads, so it only covers this fix when run with 
`-Dcamel.threads.virtual.enabled=true`.**
   
   | mode | before | after |
   |---|---|---|
   | platform | passes | passes |
   | virtual | fails, 1 task queued | passes |
   
   Verified, 161 tests selected by name (thread, executor, scheduled and split 
or multicast timeout tests, in `camel-support` and `camel-core`):
   
   - Platform threads: 0 failures, 3 skipped.
   - Virtual threads: 5 failures, 33 skipped. The same 5 fail without this 
change, so they are not caused by it, and I did not look into them: 
`SplitTimeoutCancelTaskTest.testSplitterTimeoutShouldNotExhaustThreadPool`, 
`ScheduledPollConsumerEdgeCasesTest.testConcurrentUnscheduleTask`, 
`ThreadsCoreAndMaxPoolInvalidTest.testInvalidSyntax`, 
`ThreadsKeepAliveTimeTest.testKeepAliveTime` and 
`ThreadsZeroInCoreAndMaxPoolTest.testThreadsCoreBeZero`.
   
   The full `camel-core` suite and the component modules were not run.
   
   # 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).
   
   # 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.
   
   Not run from the root folder: I ran `mvn install -Dquickly -pl 
core/camel-core -am`, and `git status` showed only the two changed files 
afterwards.
   
   # 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.
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code) on behalf of 
Adriano Machado (@ammachado)
   
   _This was generated by an AI agent and may contain inaccuracies. Please 
verify before relying on it._


-- 
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