[
https://issues.apache.org/jira/browse/CAMEL-16829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17860765#comment-17860765
]
Claus Ibsen commented on CAMEL-16829:
-------------------------------------
Your thread pool for the aggregate EiP should not be using caller-runs as all
threads in your consumer bean are busy waiting, and then the thread pool gets
exhausted under high load, and the JMS thread will then also be sleeping 5s in
the consumer bean, and then you end up with this forever. At least in the
linked test project.
It may be wiser to set thread pool to abort task when its full, and instead
have a queue size that can handle the usual load.
> camel-core - Stuck processing with nested parallel splits and custom thread
> pool
> --------------------------------------------------------------------------------
>
> Key: CAMEL-16829
> URL: https://issues.apache.org/jira/browse/CAMEL-16829
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 3.11.0
> Reporter: Samuel Padou
> Assignee: Claus Ibsen
> Priority: Minor
> Fix For: 4.x
>
>
> The cause of this issue is difficult to pinpoint, but running the following
> code, the route will be stuck indefinitely in processing:
> {code:java}
> @Component
> public static class Route extends RouteBuilder {
> @Override
> public void configure() throws Exception {
> final var executorService = new ThreadPoolBuilder(getContext())
> .poolSize(1)
> .maxPoolSize(1)
> .maxQueueSize(0)
> .build("inner");
> from("direct:main")
> .split(body()).parallelProcessing()
> .to("direct:inner?synchronous=true");
> from("direct:inner")
> .split(body()).executorService(executorService)
> .log("${body}");
> }
> }
> @Component
> public static class Runner implements CommandLineRunner {
> @Autowired
> private CamelContext camelContext;
> @Autowired
> private ProducerTemplate producerTemplate;
> @Override
> public void run(String... args) {
> final var exchange = new DefaultExchange(camelContext);
> exchange.getIn().setBody(List.of(List.of("0-0", "0-1"),
> List.of("1-0", "1-1")));
> producerTemplate.send("direct:main", exchange);
> }
> }
> {code}
> There are two important parts to reproduce the issue:
> * The forward to direct:inner with synchronous=true. This will cause an await
> here and it is the point where the route processing is stuck.
> * The inner executor, with a small pool and no queue, which will trigger the
> default CallerRuns rejection policy and run the split in the original thread
> instead of as new one.
> The cause of the stuck await seems to be linked to the way the
> AsyncProcessorAwaitManager and DefaultReactiveExecutor.executeFromQueue()
> interacts. Here the await callback to decrement the latch have been pushed in
> a back queue of the reactive worker (probably by a scheduleMain in the
> middle), but the executeFromQueue does not process the worker back queues so
> the callback is not executed and we are stuck on the await.
> I'm not sure what the solution is here, maybe the executeFromQueue should
> process back queues, or the CallerRuns rejection policy is just not supported
> in the first place but it should probably not be the default then.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
