allthingssecurity opened a new pull request, #29368: URL: https://github.com/apache/camel/pull/29368
# Description [CAMEL-26604](https://issues.apache.org/jira/browse/CAMEL-26604) With `multipleConsumers=true`, `SedaEndpoint` multicasts each message to the consumers of the queue with a `MulticastProcessor` whose outputs were `consumer.getProcessor()`, the routes of the consumers. When a consumer starts or stops (a route added, removed, started, stopped, suspended or resumed), the endpoint stops the multicast processor and creates a new one, started on the next poll. Stopping the multicast processor stopped its outputs, that is the other routes that consume from the queue, and the new one started them again. So: - an exchange that another route was processing then failed at its next step with `RouteStoppingException` and was lost (the route stayed stopped until the next message was polled); - the processors lost the state they reset on stop, such as the closed correlation keys of an aggregator. CAMEL-6374 made a stop of one route not stop the multicast for the others; this is what was left of it. Found with Fray (controlled concurrency testing for the JVM), then reproduced with plain JUnit tests. Change (`SedaEndpoint`): the outputs of the multicast processor are small wrappers (`AsyncProcessorSupport`) that call the async processor of the consumer and do not start or stop it. Each consumer already starts and stops its own processor (`DefaultConsumer`). Tests: `SedaMultipleConsumersOtherRoutesTest` (an exchange in flight in route A while route B is added; route A's processors not stopped when B starts and stops; an aggregator's closed correlation key kept). On main 3 of 3 fail; with the fix 3/3, and 20 to 40 runs each (the closed-key test checks, through an on completion of route A, that route A's copy of the second message was rejected with `ClosedCorrelationKeyException`; the multicast is parallel, so the order of the bodies is not asserted). A backport candidate for the LTS branches (the behaviour is old). camel-core seda, vm, multiple consumers and multicast tests: 338 run, 0 failures apart from `SedaConfigureTest.testConfigureIgnoreCaseLocaleIndependent`, which fails because my local camel-package-maven-plugin is older than CAMEL-26439 and regenerated the configurers (not part of this change). # 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): [CAMEL-26604](https://issues.apache.org/jira/browse/CAMEL-26604). # 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 the core modules, camel-seda and camel-core with the formatter and import-sort plugins and ran the related camel-core tests; no generated file changes. 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]
