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

   # Description
   
   [CAMEL-24958](https://issues.apache.org/jira/browse/CAMEL-24958)
   
   The Recipient List acquires a producer for every recipient up front 
(`createProcessorExchangePairs`). It released one, and stopped a 
`cacheSize(-1)` prototype endpoint, only in 
`RecipientProcessorExchangePair.done()`, which runs for recipients that were 
actually sent to. When the list stopped early (`stopOnException`, `timeout`), 
the remaining producers were never released:
   - A non-singleton producer (ftp/sftp, smb, ssh, mina sync, ...) was never 
returned to its pool. In a reproducer, 50 failing exchanges started 50 extra 
producers.
   - With `cacheSize(-1)`, the prototype endpoint and its producer were never 
stopped, not even when CamelContext stopped.
   
   This change (only in `RecipientListProcessor`):
   - Each `RecipientProcessorExchangePair` has a state (NEW, BEGUN, DONE, 
RELEASED), changed only by compare-and-set. So a producer is released exactly 
once, either when its send is done or by the Recipient List when it completes.
   - `doDone(...)` is overridden to release every pair that was never begun, 
before the callback continues the route.
   - A `beforeSend` override claims the pair (NEW → BEGUN) before any event. A 
pair that was already released is skipped: no ExchangeSending/ExchangeSent 
events, and its processor does nothing.
   - 4.23 upgrade guide: with `parallelProcessing`, a recipient whose task 
hadn't started when the Recipient List completed is now skipped instead of 
being sent to afterwards. Recipients already started keep running, as before. 
Multicast and Split keep their current behaviour here; this PR only changes the 
Recipient List, which acquires its producers up front.
   
   Tests: `RecipientListReleaseUnsentProducerTest` uses a component with a 
non-singleton producer that counts producer and endpoint starts/stops:
   - `testStopOnException`, `testStopOnExceptionParallel`, 
`testPrototypeEndpointStopped` (`cacheSize(-1)`) and `testTimeout`. Without the 
fix they fail with `expected: <1> but was: <5>` (twice), `expected: <5> but 
was: <0>` and `expected: <1> but was: <2>`.
   - `testStopOnExceptionParallelSkippedRecipientHasNoEvents` uses an 
EventNotifier and a manually driven executor, and passed 100/100 as a repeated 
test. Without the `beforeSend` claim it fails with `expected: <0> but was: <1>` 
(a Sending event for the skipped recipient).
   - `*RecipientList*,*Multicast*,*Split*,*EventNotifier*,*Event*`: 642 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.
   
   Not changed here (pre-existing, same family, could be a follow-up): if 
`createProcessorExchangePairs` throws partway (for example an invalid endpoint 
without `ignoreInvalidEndpoints`), the producers already acquired for the 
earlier recipients are not released.
   
   Merge note: this PR and #26815 both add a section at the end of the 4.23 
upgrade guide. Whichever merges second gets a trivial conflict (keep both 
sections), and I'll rebase it.
   
   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