allthingssecurity opened a new pull request, #29370: URL: https://github.com/apache/camel/pull/29370
# Description [CAMEL-26634](https://issues.apache.org/jira/browse/CAMEL-26634) Since CAMEL-20435 every start of the batch resequencer creates a new `BatchSender` thread, and a stop only interrupts the old one. The stop does not wait for the batch the old sender is sending (the resequencer completes the incoming exchanges when it queues them, so the route has nothing inflight). When the route is started again before that batch is done, the old sender goes on, as `isRunAllowed()` is true again, and both senders iterate and remove from the same `collection` (a `TreeSet`): - the new sender sends the rest of the batch while the old one is still processing an earlier exchange, so the exchanges are no longer sent one at a time in order; - the old sender's iterator then fails with `ConcurrentModificationException`; - when the processing clears the interrupt status, the old sender never ends, and two senders keep running on the same collection. Found with Fray (controlled concurrency testing for the JVM): sends to a batch resequencer while its route is stopped and started logged the `ConcurrentModificationException` in `BatchSender.sendExchanges` in 2 of 60 schedules. Change (`Resequencer.BatchSender`): - `cancel()` also sets a `cancelled` flag, and the sender loop ends on it, so the old sender ends once it has sent its batch, also when the processing cleared the interrupt status; - the sender of a new start first waits for the sender of the previous start to end (one WARN if that takes more than 10 seconds), then sends. The start itself does not wait. Why the new sender waits instead of `doStop` joining the old one: a join would block the stop for a whole batch, which the shutdown timeout does not cover (the copies being sent are not inflight), and a collection per start would undo CAMEL-20435, which keeps the collection across restarts. The interrupt is kept (unlike CAMEL-25053, which signals instead), as it wakes the sender waiting for the batch and is the existing stop behaviour. So after a restart nothing is sent by the new start until the old sender has sent its batch. As before, the old sender is interrupted by the stop and sends the rest of its batch on that thread, and a plain stop without a restart behaves as before. Tests: `BatchResequencerRestartTest` (latches, no sleep): the route is stopped and started (once, or twice) while message 1 is being processed and 2 waits in the batch, then 3 and 4 are sent. On main the mock gets 2 before 1 (2, 3, 4 are sent while 1 is still processed), and with a processor that clears the interrupt status two sender threads stay alive: 3/3 fail. With the fix 3/3, 20 runs each (60/60). Related camel-core tests (all camel-core tests with a resequencer route): 69 (3 skipped), 0 failures. # 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-26634](https://issues.apache.org/jira/browse/CAMEL-26634). # 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]
