[
https://issues.apache.org/jira/browse/CAMEL-26706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-26706 started by shashank.
----------------------------------------
> camel-core - Aggregate EIP: an AggregationStrategy whose onCompletion throws
> leaves the aggregated exchange in progress, so a recoverable repository never
> recovers it
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26706
> URL: https://issues.apache.org/jira/browse/CAMEL-26706
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Reporter: shashank
> Assignee: shashank
> Priority: Major
>
> When a group completes, {{AggregateProcessor.onSubmitCompletion}} first books
> the aggregated exchange as in progress ({{inProgressCount}} and
> {{inProgressCompleteExchanges}}), then calls
> {{aggregationStrategy.onCompletion(exchange)}}, and only after that adds the
> {{AggregateOnCompletion}} that undoes the booking. If {{onCompletion}}
> throws, nothing undoes it: the aggregated exchange is never sent, never
> failed and never confirmed.
> By then the group has been removed from the aggregation repository. A
> recoverable repository (such as {{JdbcAggregationRepository}}) has moved it
> to its completed store, but its recover task skips it on every run as
> "already in progress", so the group is neither delivered nor recovered until
> the CamelContext is restarted. The in progress count also stays above 0, so a
> stop with {{forceCompletionOnStop}} or {{completeAllOnStop}} waits until the
> shutdown timeout. With {{completionFromBatchConsumer}}, the other groups
> completed in the same batch are not submitted at all and are lost the same
> way.
> {code:java}
> from("direct:start")
> .aggregate(header("id"), strategyWhoseOnCompletionThrowsOnce)
> .aggregationRepository(recoverableRepository).completionSize(2)
> .to("mock:aggregated");
> // send A1 and A2 with id A: the sender of A2 gets the exception from
> onCompletion,
> // and A1+A2 never reaches mock:aggregated, although it is in the completed
> store
> {code}
> The javadoc of {{onCompletion}} says it must not throw. Even so, CAMEL-26575
> made Multicast, Split and Recipient List fail the exchange in that case
> instead of hanging it, and CAMEL-26309 fixed the same lost group for a
> rejected thread pool task ({{onRejectedCompletion}}), but the throw happens
> before the on completion is registered, so that fix does not cover it.
> Expected: the aggregated exchange fails as when the thread pool rejects it
> (its on completions run, so it is no longer in progress and is not confirmed,
> and a recoverable repository recovers it), it is passed to the exception
> handler, and the sender still gets the exception. The other groups of a batch
> are still sent.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
