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

   # Description
   
   [CAMEL-26633](https://issues.apache.org/jira/browse/CAMEL-26633)
   
   A loop with `breakOnShutdown` stopped looping for good once its route had 
been suspended, or stopped and started again. `LoopProcessor.prepareShutdown` 
set `shutdownPending = true` and nothing cleared it, and the shutdown strategy 
calls `prepareShutdown` also for a suspend (`suspendOnly=true`). Every later 
exchange then went through the loop without a single iteration, with no 
exception and no log.
   
   Ways to get there: a stop + start or suspend + resume of the route (JMX, dev 
console, control bus, CLI, route policies) and a CamelContext suspend + resume.
   
   Found during a Fray (controlled concurrency testing for the JVM) hunt on 
route stop and start, while reading the shutdown hooks of the EIPs. No race is 
needed: the order alone is enough.
   
   Change (`LoopProcessor`), the same as the error handlers do with their 
`preparingShutdown` flag (`RedeliveryErrorHandler`), with an upgrade guide note 
as a suspend now waits for the running loops:
   - `prepareShutdown` ignores a suspend (the route is resumed later without 
being started again);
   - `doStart` clears the flag, so only the next stop breaks out of the loops;
   - the flag is volatile (written by the shutdown thread, read by the routing 
threads).
   
   Tests: `LoopBreakOnShutdownRestartTest`: a loop after route stop + start, 
after route suspend + resume, after CamelContext suspend + resume, and a loop 
that still breaks out on a stop after a restart. On main the four fail (the 
first three: 0 iterations instead of 3; the last one never iterates). With the 
fix 4/4, and 20 runs each (80/80). Related camel-core tests (routes with a 
loop, `*Shutdown*`, `*Suspend*`, `*Resume*`): 143 more (2 skipped), 0 failures.
   
   Not changed:
   - a suspend that times out forces the shutdown and stops the consumer, which 
a resume does not start again (to be reported separately); the route needs a 
stop and start, which also resets the flag;
   - a stop aborted after its timeout (`abortAfterTimeout`) keeps the route 
running with its loops broken, as before.
   
   # 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-26633](https://issues.apache.org/jira/browse/CAMEL-26633).
   
   # 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 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]

Reply via email to