[
https://issues.apache.org/jira/browse/CAMEL-26888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-26888 started by shashank.
----------------------------------------
> camel-core - an Error of the watermark expression of a split, or of the
> aggregation strategy of an enrich, is not handled as an exception
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26888
> URL: https://issues.apache.org/jira/browse/CAMEL-26888
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Reporter: shashank
> Assignee: shashank
> Priority: Minor
>
> Follow-up of CAMEL-26741 and CAMEL-26710. Three places still catch only
> {{Exception}}, so an {{Error}} that is not a {{VirtualMachineError}} (for
> example a {{NoClassDefFoundError}} of a class or function used there) is not
> handled as an exception:
> * the watermark expression of a split
> ({{Splitter.WatermarkProcessorExchangePair.done}}): CAMEL-26710 fails the
> item when the expression throws, as a throw there made the split exchange
> hang; an {{Error}} still escapes to the thread that drives the split and
> leaves the split exchange inflight;
> * the aggregation strategy of an {{enrich}} ({{Enricher}}): it runs in the
> callback of the resource exchange, so an {{Error}} escapes that callback and
> the exchange stays inflight;
> * the aggregation strategy of a {{pollEnrich}} ({{PollEnricher}}): the
> {{Error}} escapes {{process}}, the error handler fails the exchange with it
> (not with "Error occurred during aggregation"), and the completions of the
> polled resource never run (a polled file is not released).
> Expected: as for the processors after CAMEL-26741, such an {{Error}} is
> handled as an exception (and a {{VirtualMachineError}} is left as before).
> Not part of this issue: the rest of what CAMEL-26866 left for a separate
> JIRA. The {{onPrepare}} processor of a multicast, split or recipient list and
> the step of a part in the transacted task are in {{MulticastProcessor}},
> which the open work of CAMEL-26824 changes, so they come after it. The worker
> of the reactive executor stays as it is: if it swallowed an {{Error}}, a
> synchronous caller would wait for ever (no callback comes), so such an
> {{Error}} is caught where it is thrown, as here.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
