davsclaus opened a new pull request, #26847: URL: https://github.com/apache/camel/pull/26847
_Claude Code on behalf of Claus Ibsen (davsclaus)_ JIRA: https://issues.apache.org/jira/browse/CAMEL-24991 A deep review of the Aggregate EIP (`AggregateProcessor` and the aggregate package) found the bugs below. Each fix has a test that fails without it. 1. **Force completion stopped at the first group another node had taken.** With optimistic locking, `forceCompletionOfAllGroups`, `forceCompletionOfGroup` and the two force-discarding methods let an `OptimisticLockingException` escape. The first group that another Camel instance had already completed stopped the loop, so the remaining groups were left in the repository. The exception reached the caller: the aggregate controller, JMX, `completeAllOnStop`/`forceCompletionOnStop` at shutdown, or `completionOnNewCorrelationGroup`. The completion interval task already handles this for each group, and the force methods now do the same. 2. **Force discarding did not discard unless `discardOnAggregationFailure` was enabled.** The force-discarding methods called `onCompletion` with "aggregation failed", which only discards when `discardOnAggregationFailure=true`. With the default, the group was removed from the repository but never confirmed and not counted as discarded. With a recoverable repository, the recover task could later find it and send it. The group is now discarded in both cases. 3. **The optimistic locking retry delay was not capped by default.** `OptimisticLockRetryPolicy` defaulted `maximumRetryDelay` to 0 (no cap), but its documented default is 1000 ms. With `optimisticLocking()` and no retry policy, the exponential back-off doubled on every attempt: 51 seconds at attempt 10, and hours soon after. With unlimited retries, the shift overflowed at attempt 58, giving a negative delay and retries without any back-off. The default is now 1000 ms, and the shift can no longer overflow. Setting `maximumRetryDelay` to 0 still means no cap. 4. **Upgrade guide** (4.23) entry for item 3. ### Related work in this area (not repeated here) - Merged: CAMEL-24941 (#26785) and CAMEL-24946 (#26791). - Open: CAMEL-24943 (#26788), CAMEL-24944 (#26789) and CAMEL-24945 (#26790). #26788 and #26789 both change the signature of `doAggregation`, so whichever merges second will need a rebase. #26788 also changes the force-discarding methods; this PR touches the same lines, so one of the two will need a small rebase. Separately, #26788 noticed that force discarding returns the exchange when `discardOnAggregationFailure` is false and only clears its mark; item 2 here fixes the discard itself. ### Not changed (left for follow-up) - **`AGGREGATION_COMPLETE_ALL_GROUPS` on an existing group.** When the aggregation strategy sets this flag while the current group already exists, the current group is force-completed and sent, and then the combined result is added back to the repository. The earlier parts of the group are then sent twice. The documented use is to set the flag when a new group starts, which works correctly. Whether the current group should be included is a design question. - **The lock is created at the end of `doStart`.** It is created after the interval and recover tasks are scheduled, so a very short `completionInterval` could run the task before the lock exists. The task logs the resulting error and runs again on the next interval. - **Redelivery state is not removed.** The recover task does not remove the redelivery state of an exchange after moving it to the dead letter channel, so a small entry is kept for each exhausted exchange. ### Tests - New `AggregateOptimisticLockingForceCompletionTest` and `AggregateForceDiscardingConfirmTest`, and new tests in `OptimisticLockRetryPolicyTest`. Each fails without its fix. - All 248 `*Aggregat*` tests and `OptimisticLockRetryPolicyTest` pass. 🤖 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]
