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

   # Description
   
   [CAMEL-26603](https://issues.apache.org/jira/browse/CAMEL-26603)
   
   With `forceCompletionOnStop`, the messages that a consumer still routed 
while its route stopped were lost.
   
   When a route stops, `DefaultShutdownStrategy` first prepares the route 
services, so the aggregator completes its groups, and then waits for the 
inflight and pending exchanges. Consumers that defer their shutdown (seda, 
direct and others) keep routing during that wait; seda drains its queue. Those 
messages started new groups. The strategy prepared the services again only 
after it had stopped the deferred consumers, but stopping a `DefaultConsumer` 
stops its processor, the route, so the aggregated exchange of these groups 
failed with `RouteStoppingException`, logged at WARN by the aggregator, and the 
messages were lost although they had been accepted (and taken off the seda 
queue).
   
   Found with Fray (controlled concurrency testing for the JVM): two threads 
sending to an aggregator with `forceCompletionOnStop` while a third stops the 
route; all sends succeeded, but only the first group came out.
   
   Change (`DefaultShutdownStrategy.ShutdownTask`): after the deferred 
consumers have been prepared for the shutdown (a seda consumer has then drained 
its queue and its threads have ended), and before they are stopped, the route 
services are prepared again (not forced), so the aggregator completes the 
groups of these messages while the route can still process them; it waits for 
its in-progress completions there. Not done for a suspend (the consumers are 
only suspended, the routes keep running) or after a timeout (the task returns, 
also when the timeout happened while the deferred consumers were prepared, such 
as a seda consumer draining its queue), and a forced shutdown passes 
`forced=true` as the neighbouring calls do. The other services that implement 
`prepareShutdown` (error handlers, loop, wire tap, on completion, JTA error 
handler, backlog debugger) only set a flag or do nothing, so a second call 
changes nothing for them.
   
   Not covered: a message that a deferred consumer such as direct still accepts 
after this point (between the second prepare and the stop of the consumer) is 
completed by the last prepare, as before, which fails. And when the whole 
CamelContext stops, an aggregated exchange sent to a seda queue whose route has 
already drained it stays in that queue.
   
   Tests: `AggregateForceCompletionOnStopLateMessagesTest` (one group 
aggregated, one message in flight, two in the seda queue, then `stopRoute` or 
`CamelContext.stop()`; latches, no sleeps). On main both fail (only `[m0]` 
comes out); with the fix both pass, and 20 runs each. camel-core aggregator 
package, shutdown strategy, graceful shutdown, abort after timeout, 
suspend/resume, route policy, route controller, seda and direct tests: 535 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-26603](https://issues.apache.org/jira/browse/CAMEL-26603).
   
   # 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