[
https://issues.apache.org/jira/browse/CAMEL-24990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-24990 started by Claus Ibsen.
-------------------------------------------
> camel-core - Multicast, Split and Recipient List EIPs: fix bugs found in a
> deep review
> --------------------------------------------------------------------------------------
>
> Key: CAMEL-24990
> URL: https://issues.apache.org/jira/browse/CAMEL-24990
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
>
> A deep review of the Multicast EIP family (MulticastProcessor, Splitter,
> RecipientList and RecipientListProcessor) found the bugs below. Each one was
> reproduced against 4.23.0-SNAPSHOT.
> # *A streaming split that stops early reads the rest of the input.* When the
> split finished before the input was consumed (stopOnException or a timeout),
> MulticastProcessor.doDone iterated the pairs again to release their
> exchanges. For a streaming split this pulled every remaining part from the
> iterator. Each part was prepared and wrapped in an error handler, and
> onPrepare ran on it, even though it was never routed. With 100 parts and a
> failure at the second part, onPrepare ran 100 times instead of 2. With a
> timeout, the timeout thread iterated the input while the splitter thread
> could still be reading it, and a very large or endless stream was read to the
> end.
> # *A transacted recipient list shares transaction context data across
> transactions.* RecipientListProcessor kept the TRANSACTION_CONTEXT_DATA map
> in a field that was created once and then given to the copies of every
> transacted exchange. camel-jpa stores the EntityManager of a transaction in
> that map, so a later transaction could reuse the EntityManager of an earlier
> one, which is already closed. The map is now created per exchange, as the
> Multicast and Splitter do.
> # *A recipient that cannot be resolved leaks the producers of the recipients
> before it.* The producers are acquired while the recipients are resolved.
> When a later recipient failed, the exception was thrown before any pair was
> sent, and the producers already acquired were never released. Prototype
> endpoints (cacheSize=-1) were never stopped.
> Related work by others that this does not repeat: CAMEL-24958 (release
> producers of recipients not sent to), CAMEL-24960 (rejected parallel
> sub-exchange task) and CAMEL-24959 (trailing null part in a parallel
> streaming split, PR open).
> _Claude Code on behalf of Claus Ibsen_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
