[jira] [Updated] (CAMEL-16829) camel-core - Stuck processing with nested parallel splits and custom thread pool

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

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

Claus Ibsen updated CAMEL-16829:
--------------------------------
    Summary: camel-core - Stuck processing with nested parallel splits and custom thread pool  (was: Stuck processing with nested parallel splits)

> 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
>            Priority: Major
>             Fix For: 3.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.3.4#803005)