allthingssecurity opened a new pull request, #28641: URL: https://github.com/apache/camel/pull/28641
# Description [CAMEL-26288](https://issues.apache.org/jira/browse/CAMEL-26288) `QuickfixjEndpoint` supports multiple consumers and delivers each FIX event to all of them, and every route that consumes from the same `quickfix:` uri shares the endpoint. When a route is removed, the core stops the endpoint of its consumer, also when other routes still consume from it, and `QuickfixjEndpoint.doStop` cleared the whole list of consumers. The consumers of the other routes stayed started but no longer got any message, logon or other event of the session; nothing was logged and nothing failed. Example: two routes `from("quickfix:fix.cfg?sessionID=FIX.4.4:ACCEPTOR->INITIATOR")`, one processing orders and one recording session events; removing the second (a reload, a route template removed) silently stopped the first from receiving orders until it was restarted. Changes: - `QuickfixjEndpoint.doStop` is removed. Each consumer already takes itself off the endpoint when it stops (`QuickfixjConsumer.doStop` -> `removeConsumer`, which also releases its engine reference), so the list only held consumers that were still running. - `QuickfixjEndpoint.removeConsumer` returns at once for a consumer that is not in the list, so it releases an engine reference only for a consumer that took one. Removing a route that never started (`autoStartup=false`, a standby route) stops its consumer (`RouteService` stops the consumer, which is still `INITIALIZED`, and `BaseService.stop` runs `doStop`): on main every such removal released one reference of the engine, and with `eagerStopEngines=true` (the default) enough of them stopped the engine of the routes still running, which then went off the session too. A consumer whose start failed is still paired: `addConsumer` adds it to the list first, so the `stop()` of the failed start releases its reference. - No option, generated file or upgrade guide change. - Backport: camel-4.22.x, 4.18.x and 4.14.x have the same `doStop` (read, not run). Tests: - New `QuickfixjRemoveRouteTest`: an acceptor and an initiator session over QuickFIX/J's in-JVM VM pipe transport (as `QuickfixjComponentTest`), configured with `QuickfixjConfiguration`; two consumer routes on the acceptor session, the initiator sends a FIX `Email`. - `removingOneOfTwoConsumerRoutesKeepsTheOtherReceiving` fails on main (3 runs): `mock://a Received message count. Expected: <1> but was: <0>`. - `stoppingOneOfTwoConsumerRoutesKeepsTheOtherReceiving` (a stop without remove does not stop the endpoint) passes on main and with the change; it is a control. - `removingRoutesThatNeverStartedKeepsTheOthersReceiving`: 8 standby routes (`autoStartup(false)`) on the same endpoint are added and removed, then the initiator sends. Without the check in `removeConsumer` the engine is stopped and the send fails (`CannotSendException: Cannot send FIX message`). - camel-quickfix: 49 tests, 0 failures. The formatter and import-sort plugins ran. How it was found: a code sweep for endpoints whose `doStop` releases something that other routes on the same uri still use, after a random lifecycle-sequence harness found the same kind of defect in camel-disruptor. Not changed: `QuickfixjProducer` releases its engine reference in `doStop` without such a check; a producer is started before it is stopped on every path I found (a route that never started never created its producer), so I left it. `onEvent` passes an exception of one consumer's route out of the loop, so the consumers after it in the list do not get that event; that is a separate issue, for a follow-up JIRA. Also not changed: the core stops the endpoint of a removed route's consumer even when other routes still use it. Other components whose endpoint `doStop` releases something the other routes of the same uri still use may have the same problem; I can file a follow-up JIRA for the ones I can reproduce. # 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-26288) filed for the change (usually before you start working on it): [CAMEL-26288](https://issues.apache.org/jira/browse/CAMEL-26288). # 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 camel-quickfix and ran its tests, including the formatter and import-sort plugins. 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]
