[
https://issues.apache.org/jira/browse/CAMEL-17144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17436313#comment-17436313
]
Jeremy Ross commented on CAMEL-17144:
-------------------------------------
I set this up to run 10 times, and to log the "parent" exchange Id (not the
exchanges created by the splitter). In all 10 runs, the "Split done" log
statement is reached before a single child of the split has a chance to log.
Even with the splitter's parallel processing mode, all the split children
should complete before the "split done" logging statement. So it seems there
may be an issue here.
[~davsclaus] what do you think?
[^parallel split test.txt]
> Split with aggregation strategy does not wait all substasks to be completed
> ---------------------------------------------------------------------------
>
> Key: CAMEL-17144
> URL: https://issues.apache.org/jira/browse/CAMEL-17144
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 3.0.0, 3.12.0
> Reporter: Thomas Sergent
> Priority: Major
> Attachments: parallel split test.txt, test-camel-scheduler.zip
>
>
> Hi after trying to update from camel 2.25.4 to 3.12 I have a trouble with the
> usage of the split with parallelProcessing enabled. I cannot share my project
> but here is a little sample to reproduce the issue.
>
> {code:java}
> from("scheduler:testBug?initialDelay=1000&useFixedDelay=true&delay=5000&greedy=true")
> .to("direct:test");
> from("direct:test")
> .log("Before the processor the body must be empty : [${body}]")
> .process((exchange) -> {
> exchange.getIn().setBody(IntStream.range(0,
> 10).mapToObj(i -> "" + i).collect(Collectors.toList()));
> })
> .log("Exchange updated number form 0 to 9 : [${body}]")
> .split(body())
> .parallelProcessing(true)
> .log("The child exchange: ${body}")
> .end()
> .log("Split done: [${body}]")
> .setProperty(Exchange.SCHEDULER_POLLED_MESSAGES,
> simple("false"));
> {code}
>
> With camel 2.25.X the expected behavior (to process each split before
> returning to the caller) is ok but not with the 3.X where the process loop
> indefinillty.
>
> Note: I have added a kill switch to avoid process to be hanged.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
