allthingssecurity opened a new pull request, #27989: URL: https://github.com/apache/camel/pull/27989
# Description [CAMEL-25709](https://issues.apache.org/jira/browse/CAMEL-25709) The completion timeout of the Aggregate EIP is driven by `AggregationTimeoutMap`, a `DefaultTimeoutMap`. Its purge first removes the expired entries from the map and then calls the listeners; the aggregator's listener, `onEviction`, reads the group from the aggregation repository, removes it and sends it on. `DefaultTimeoutMap.emitEvent` ignores an exception of a listener without logging it. So when the repository failed once while the timeout checker completed a group (only `OptimisticLockingException` is handled in `onEviction`), for example a `JdbcAggregationRepository` whose database was not reachable for a moment, the timeout entry was already gone and nothing tried again: the group stayed in the repository and was never sent, unless another message with the same correlation key arrived or the route was restarted, and nothing was logged. CAMEL-24141 fixed the same failure mode for the recover task and the completionInterval task. Changes (`AggregateProcessor.AggregationTimeoutMap` only): - The body of `onEviction` moved, unchanged, into `doOnEviction`. `onEviction` calls it in a `try`; on an exception it logs a WARN (correlation key and cause; the stack trace at DEBUG) and puts the key back into the timeout map with `putIfAbsent`, to be tried again after `completionTimeoutCheckerInterval`. An entry that a new message for the key has put in the meantime is kept. - If the group had already been removed when the error came (for example a custom `AggregationStrategy.timeout` threw), the next try finds no group and does nothing, as for a group completed by another node. What users can notice: such a group is now completed at a later check, with a WARN line for each failed try. A group that the repository can never read is logged once per check interval (1 second by default) until it is removed, as the completionInterval and recover tasks log each failing run. No option or default changes, so no upgrade guide entry. Tests: - New `AggregateTimeoutRepositoryExceptionTest` (2 tests): a `MemoryAggregationRepository` wrapper fails exactly once, in `get` or in `remove`, on the call made by the timeout checker (`completionTimeout(200)`, `completionTimeoutCheckerInterval(50)`); the group must still reach `mock:result`. Bounded waits only (`MockEndpoint.assertIsSatisfied(context, 10, SECONDS)`), no sleeps. - Without the change both tests fail: `mock://result Received message count. Expected: <1> but was: <0>`, and the test log has no line about the failure. - With the change the camel-core tests pass: 8185 run, 0 failures, 0 errors, 45 skipped (the modules camel-core depends on were built and tested in the same run). What is not changed: - `DefaultTimeoutMap.emitEvent` still ignores listener exceptions; the other users of the timeout map (the JMS, SJMS, Netty and RocketMQ reply managers) are not touched. - The order in `onCompletion` (the group is removed before `AggregationStrategy.timeout` is called) is not changed. What was not run: the persistent aggregation repositories (camel-sql, camel-cassandraql, camel-redis, ...) against a real store. # 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-25709](https://issues.apache.org/jira/browse/CAMEL-25709). # 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 camel-core and the modules it depends on, 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]
