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

   # Description
   
   [CAMEL-25010](https://issues.apache.org/jira/browse/CAMEL-25010)
   
   The restart attempt of `DefaultSupervisingRouteController` only checked 
`CamelContext.isRunAllowed()` and then called `doStartRoute`, which takes the 
controller lock and starts the route. `stopRoute` takes the same lock and 
cancels the route's restart task (`RouteManager.release`). Cancelling only 
prevents future attempts: `BackOffTimerTask.run()` checks the status once, on 
entry.
   
   So an attempt that was already running started the route after `stopRoute` 
had returned. This happens whenever the attempt waits for the controller lock 
during the stop, and the lock is shared by all routes, so a slow stop of any 
other route is enough. The route then ran without supervision (it has no 
restart task any more), and nothing reported it.
   
   This change: the attempt now checks under the controller lock, before it 
starts the route, that:
   - its task is still the route's restart task (`routes.get(r) == task`);
   - the task is still active (a manual stop or start cancels it);
   - Camel is not stopping.
   
   If any check fails, it logs that the attempt was cancelled and gives up 
without starting the route. `RouteManager.start` runs under the same lock, so a 
new task is always registered before its first attempt can check.
   
   Tests: new `DefaultSupervisingRouteControllerStopWhileRestartingTest`. A 
route fails to start. Its first restart attempt is held in the 
`RouteRestartingEvent` notifier while the cause is fixed and the route is 
stopped manually. The attempt is then released, and the route must stay 
stopped. Latches and Awaitility, no sleeps. Without the fix:
   ```
   AssertionFailedError: expected: <Stopped> but was: <Started>
   ```
   With the fix it passes. `*BackOff*,*Supervising*,*RouteController*` in 
camel-util, camel-core and camel-management: all pass.
   
   Found with a TLA+ model of the supervising route controller, then reproduced 
against the real classes, also without holding any thread: route r1 waits to 
restart while stopping route r2 holds the controller lock (3 of 3 runs 
restarted r1 after `stopRoute("r1")` returned). With only this change, "no 
restart after the user stopped the route" holds in the model with up to 3 user 
operations and 3 restart tasks (36k states). The same harness scenarios now 
leave the route stopped.
   
   Related:
   - #26859 (CAMEL-25001) changes `RouteManager.release()`. This change is in 
the attempt of `RouteManager.start()`. The two apply together without conflicts.
   - #26867 (CAMEL-25007, CAMEL-25008) fixes two other issues found by the same 
model: a deadlock between the restart task lock and the controller lock, and a 
cancelled restart task that completes twice and removes the route's new restart 
task. This change already stops such an orphaned task from starting the route, 
but the route's restart state and `hasUnhealthyRoutes()` stay wrong until 
#26867 is merged. A cancelled attempt that gives up here also completes its 
task, and #26867's `routes.remove(r, task)` makes sure that doesn't remove a 
newer task. The two PRs touch different parts of the file and merge without 
conflicts.
   
   # 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). 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]

Reply via email to