[jira] [Resolved] (CAMEL-24990) camel-core - Multicast, Split and Recipient List EIPs: fix bugs found in a deep review

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

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

Claus Ibsen resolved CAMEL-24990.
---------------------------------
    Fix Version/s: 4.23.0
       Resolution: Fixed

Fixed in https://github.com/apache/camel/pull/26846, merged as be76af8efb2c.

> 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
>             Fix For: 4.23.0
>
>
> 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)