allthingssecurity commented on PR #28710: URL: https://github.com/apache/camel/pull/28710#issuecomment-6528575208
@davsclaus thanks, all in b40197bab021 (fast-forward on 6416ceb25b02). **Dependent modules**, built against this PR's camel-core (the core modules in the reactor), unit tests only (`-DskipITs`, no Docker): | module | tests | failures | |---|---|---| | camel-http | 307 | 0 | | camel-netty-http | 354 | 0 | | camel-rest | 129 | 0 | | camel-undertow | 239 | 0 | | camel-vertx-http | 113 | 0 | | camel-main | 306 | 0 | | camel-kamelet | 151 | 1 (`KameletRouteChecksumTest`, also fails with main's `AbstractCamelContext`: our offline environment) | camel-core, the lookup/component/CamelContext/rest tests (with `CamelContextDeadlockTest`): 1481 tests, the same results as main per class (`RouteChecksumTest` 7 on both). **The promised comment** is on the `componentsCreatedWithoutAutoStart.put`: the entry is kept after the creator starts the component, is not consulted again, and goes with `removeComponent` or context stop. **Low items** - Context-init window: fixed. Another thread now starts or waits for the component only when the context is started, or starting after `doStartCamel` has run its "ensure components are started" loop (a `componentsStarted` flag, set after the loop and reset at stop). So a component created during init, or added while the context starts, is left to that loop, with its startup step and `FailedToStartComponentException`. The "while CamelContext starts" case of the PR still works, because `onCamelContextStarting` runs after the loop. Test: `testComponentAddedBeforeCamelContextStartsIsStartedByCamelContext` (fails on 6416ceb). - Failed start: fixed. The creator and the waiting threads now start the component under a start lock per name that the context keeps, so the start runs once. Only the thread that ran the start gets its failure. A thread that gets the lock afterwards gets the failed component back, as on main, and does not init and start it again. A side effect: only the thread that starts the component registers it as a `StartupListener`. The creator of a component that is not new when it is created (a registry bean stopped by `removeComponent`, or shut down by a restart) still starts it, as on main. Tests: `testOtherThreadDoesNotStartTheComponentAgainWhenItFailedToStart` (fails on 6416ceb: started twice) and the control `testStoppedComponentFromTheRegistryIsStartedByItsCreator`. - `RouteBuilder.customize` on a started context: same as main. I've drafted a follow-up JIRA (`customize` would start the component after applying its code when the context is already started) and will link it here once it is filed. New tests and `CamelContextDeadlockTest`: 20 runs in one JVM, 0 failures. Every new test also fails against main's class, the previous commit, or a mutant. PR body updated. _Claude Code on behalf of allthingssecurity_ -- 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]
