[
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)
