Claus Ibsen created CAMEL-24990:
-----------------------------------

             Summary: 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


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)

Reply via email to