allthingssecurity opened a new pull request, #26790: URL: https://github.com/apache/camel/pull/26790
# Description [CAMEL-24945](https://issues.apache.org/jira/browse/CAMEL-24945) With optimistic locking, `onCompletion` removed the group from the repository and then called `timeoutMap.remove(key)` without a lock. If another exchange started a new group for the same key in between (registering its timeout before its add), the completing thread removed the new group's timeout. The new group then never completed by timeout. This change, with optimistic locking only: - `onCompletion` no longer removes the timeout entry. A leftover entry is harmless: the eviction reads the group and removes it with a compare-and-set, and every new group refreshes the entry before it is added. - `onEviction` no longer skips an entry because its exchange id is in progress. With leftover entries that id can belong to a completed group while a newer group for the key is waiting. The compare-and-set already prevents completing a group twice. Both halves are needed. With only the first, a group can still be stranded (m1/m2 starting groups concurrently, then m2's group completing). The TLA+ model found that, and so does a unit test with a repository that keeps exchange ids, like JDBC. Pessimistic locking is unchanged. Tests: new `AggregateOptimisticLockingTimeoutTest`, where timeouts only start when the test allows it. Without the fix, 2 fail; with only the first half, 1 fails. With the full fix, both pass. The aggregator suites pass. Side effects, optimistic locking only: a completed group's timeout entry stays until it expires, and its eviction costs one repository `get`. With several instances sharing a repository, an old entry can complete another instance's newer group for the same key up to one timeout early, the same way cross-instance timeouts already behave. Found with a TLA+ model of the Aggregate EIP (a group without a timeout), then reproduced against the real classes. # 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. -- 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]
