davsclaus opened a new pull request, #26851: URL: https://github.com/apache/camel/pull/26851
_Claude Code on behalf of Claus Ibsen (davsclaus)_ JIRA: https://issues.apache.org/jira/browse/CAMEL-24995 A deep review of the Wire Tap, OnCompletion, Threads, Delay and Resequence EIPs found one bug, in the Wire Tap EIP. The fix has a test that fails without it. **A graceful shutdown did not wait for tapped exchanges queued in the wire tap thread pool.** `WireTapProcessor` reports its pending exchanges to the shutdown strategy through `ShutdownAware.getPendingExchangesSize()`. It only counted a tapped exchange once its task started running. Tapped exchanges still waiting in the thread pool queue were not counted, so a graceful shutdown did not wait for them. The thread pool was then shut down with those tapped messages still queued, and they were lost. The count now goes up when the task is submitted and down when it completes, or straight away if the thread pool rejects it. Camel's own rejection policies (`Abort`, `CallerRuns`, `Block`) either run the task or throw. A custom thread pool with a discard policy would silently drop a task without running it; in that case the count stays up and shutdown waits until its timeout, rather than returning early and losing messages. The test gives the wire tap a single-thread pool and blocks that thread with a task of its own, so the tapped exchanges wait in the queue. It then checks that they count as pending. It does not rely on timing. ### Reviewed without changes - **OnCompletion:** in `BeforeConsumer` mode with `useOriginalMessage`, the original message replaces the response, because that mode works on the real exchange. This is by design: the mode exists so that `onCompletion` can change the response. - **Threads:** when the processor is stopped, `ThreadsProcessor.process()` throws instead of failing the exchange. This only happens during shutdown. - **Delay:** no issues found. - **Resequence:** `StreamResequencer.process()` waits for free capacity with no timeout, so a caller blocked on a full stream resequencer could hang during shutdown. Left for a follow-up with its own test. - **Wire tap stream copies:** with `copy=true`, a stream-cache body is copied twice (once in `configureCopyExchange`, again in `configureExchange`). I checked whether the extra copy leaks spool files, and it does not: the spool file is deleted when both exchanges are done. So it is only wasted work. The Idempotent Consumer and Cache EIPs in this area are covered by outside work: CAMEL-24953 (#26814, merged) and CAMEL-24954 (#26815, open). ### Tests - New `WireTapPendingExchangesTest`, which fails without the fix: 0 pending instead of 3. - All 30 `WireTap*` tests pass. - The full `core/camel-core` suite passes: 7568 tests, 0 failures, 44 skipped. `RestProducerUnresolvedPathWarnTest` was flaky and passed on rerun; it does not touch the changed code. 🤖 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]
