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

   # Description
   
   [CAMEL-24960](https://issues.apache.org/jira/browse/CAMEL-24960)
   
   A parallel Multicast, Split or Recipient List on a thread pool that rejects 
tasks (for example `Abort` with a bounded queue) hung forever when a 
**sub-exchange** task was rejected. The caller never got a reply, and the 
exchange stayed in the inflight repository. `schedule()` catches 
`RejectedExecutionException` and only handles it for a `Rejectable` runnable, 
which is the multicast task itself (CAMEL-16829). The sub-exchange task from 
`completion.submit(...)` isn't `Rejectable`, so the rejection was swallowed. 
The sub-exchange had already been counted as sent, so the aggregation never 
completed. Before CAMEL-16829, this rejection propagated into `run()`'s catch.
   
   This change:
   - `schedule()` rethrows the rejection for a runnable that isn't 
`Rejectable`. It reaches the catch in `MulticastReactiveTask.run()`, which 
fails the exchange with the executor's `RejectedExecutionException`, the same 
way `reject()` already does for the task itself. Only the parallel path is 
affected.
   - The failure paths of the multicast task (`reject()`, the catches in both 
`run()` methods, `aggregate()` and `timeout()`) now go through a new `doFailed` 
/ `doTimeoutFailed`. Only the thread that completes the task sets the 
exception. Before this, a failure that happened after the exchange was already 
completed (by the timeout or by `stopOnException`) was still written onto the 
exchange the caller had got back. Such a late exception is now logged at debug 
level instead.
   
   Tests:
   - `MulticastParallelSubTaskRejectedTest`: split with one element, multicast, 
and recipient list, each on a pool with one thread, no queue and `Abort`. 
Without the fix, all 3 fail with `java.util.concurrent.TimeoutException` (the 
callback is never invoked). With it, they complete with 
`RejectedExecutionException` and nothing stays inflight.
   - `MulticastParallelSubTaskRejectedAfterDoneTest`: a parallel streaming 
split with `stopOnException`. The exchange is completed by the failing part, 
and then the next sub-task submission is rejected. It is deterministic, driven 
by latches and a pool shutdown, and passed 200/200 as a repeated test. Without 
the `doFailed` change it fails with `expected: <CamelExchangeException> but 
was: <RejectedExecutionException>`.
   - `*Multicast*,*Split*,*RecipientList*,*ThreadPoolAbort*`: 581 tests, 0 
failures. Full camel-support and camel-core suites with this PR and the other 
open Multicast, Recipient List and Idempotent Consumer fixes applied together 
on current `main`: 125 + 7516 tests, 0 failures.
   
   Merge note: #CAMEL_24959_PR (CAMEL-24959) moves the loop in 
`MulticastTask.aggregate()` into a new `aggregateCompleted()`. Whichever of the 
two merges second has a small conflict there, and that catch should call 
`doFailed(e)`. I'll rebase whichever PR is second. I also checked the two 
together, and the full camel-core suite passes.
   
   Found with a TLA+ model of the multicast task, then reproduced against the 
real classes.
   
   # 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), on behalf of 
allthingssecurity. The commits carry a `Co-Authored-By` trailer.
   
   🤖 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]

Reply via email to