[jira] [Assigned] (CAMEL-24991) camel-core - Aggregate EIP: fix bugs found in a deep review

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-24991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen reassigned CAMEL-24991:
-----------------------------------

    Assignee: Claus Ibsen

> camel-core - Aggregate EIP: fix bugs found in a deep review
> -----------------------------------------------------------
>
>                 Key: CAMEL-24991
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24991
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-core
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>            Priority: Major
>
> A deep review of the Aggregate EIP (AggregateProcessor and the aggregate package) found the bugs below. Each one was reproduced against 4.23.0-SNAPSHOT.
> # *Force completion stops at the first group another node has 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, and the exception reached the caller (the aggregate controller, JMX, completeAllOnStop/forceCompletionOnStop at shutdown, or completionOnNewCorrelationGroup). The completion interval task already handled this per group, and the force methods now do the same.
> # *Force discarding a group does not discard it unless discardOnAggregationFailure is enabled.* forceDiscardingOfGroup and forceDiscardingOfAllGroups rely on onCompletion discarding a failed aggregation, which it only does with 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 pick it up and send it.
> # *The optimistic locking retry delay is not capped by default.* OptimisticLockRetryPolicy used a maximumRetryDelay of 0 (no cap), while its documented default is 1000 ms. With optimisticLocking() and no retry policy, the exponential back-off doubled on each 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 no longer overflows.
> Related work by others in this area that this does not repeat: CAMEL-24941 and CAMEL-24946 (merged), and CAMEL-24943, CAMEL-24944 and CAMEL-24945 (PRs open).
> _Claude Code on behalf of Claus Ibsen_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)