allthingssecurity opened a new pull request, #26992: URL: https://github.com/apache/camel/pull/26992
# Description [CAMEL-25012](https://issues.apache.org/jira/browse/CAMEL-25012) This is the follow-up that @davsclaus asked for in #26870: `WireTapProcessor` has the same leak as the parallel onCompletion fixed there. Since #26851 (CAMEL-24995), the wire tap counts a tapped exchange as pending from when its task is submitted to the thread pool, and the task uncounts itself when it is done. When a graceful shutdown times out, `doShutdown` calls `shutdownNow` on the wire tap's own thread pool. That drops the tasks still queued in the pool. They never run, so they are never uncounted, and `getPendingExchangesSize()` keeps reporting them. So the wire tap keeps reporting pending exchanges that will never be sent, and a later graceful shutdown that asks this processor waits the full shutdown timeout for them, as described for onCompletion in #26870. This change: - `doShutdown` subtracts the number of tasks returned by `shutdownNow` from the task counter, the same as `OnCompletionProcessor` in #26870. Running tasks are interrupted and uncount themselves as before. - Only a thread pool that the wire tap created itself is shut down (`shutdownExecutorService`), so every task in it is a wire tap task. - As in #26870, the counter is not reset when the processor is started: after a forced `stopRoute` the thread pool is not shut down, and its tasks keep running and uncount themselves after a `startRoute`, so a reset could make the counter negative. No upgrade guide entry: the only visible change is that a graceful shutdown no longer waits for tapped exchanges that were dropped. Tests: new `WireTapForcedShutdownTest`, modelled on `OnCompletionParallelProcessingForcedShutdownTest` from #26870. A wire tap uses a thread pool with one thread. The first tapped exchange blocks in the tap route, and the second waits in the queue. Both are pending. The test stops the CamelContext with a shutdown timeout of 1 second, so the pool is shut down, and checks that no tapped exchange is pending and that the queued one was never sent. Without the main-code change it fails: ``` WireTapForcedShutdownTest.testForcedShutdownDropsQueuedTap No tapped exchange should be pending after the thread pool is shut down ==> expected: <0> but was: <1> ``` With the change, `*WireTap*,*Shutdown*` in camel-core pass: 77 tests, 0 failures (2 skipped). # 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. (I built and tested the affected modules, including the formatter and import-sort plugins. 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]
