[
https://issues.apache.org/jira/browse/CAMEL-16927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Klimczak updated CAMEL-16927:
-----------------------------------
Description:
My scenario:
# Http client -> Transactional servlet consumer
# Servlet route calls java bean
# Java bean calls another route using Camel Proxy and direct-vm
# CamelInvocationHandler calls direct-vm route and then hangs as route is
never executed, waiting for worker
At this point it all is deadlocked and it never ends.
From what I can see the problem happens in DefaultReactiveExecutor.Worker.
>From debugging I can see there are two DefaultReactiveExecutor.Workers at the
>point of deadlock.
At point 3, Worker number 2 executes SimpleTask which waits for it to finish-
this task is to execute bean as per step 3.
Bean execution then attempts to trigger another route using Camel Proxy and
direct-vm, but because it schedules direct-vm processor to the same Worker 2
which is currently processing current task it all deadlocks.
I have confirmed above in debugging, will try to come up with simple test case
as our scenario is rather complex and involves multiple projects.
Immediately after scheduling on Worker number 2 the direct-vm processor,
Worker 1 executes executeFromQueue (triggered by countdownLatch waiting for
direct-vm call to finish) which makes me thinking that direct-vm call has been
added to wrong Worker.
Unfortunately for us this is blocker as our solution which was working
perfectly fine with camel 2 is not working.
was:
My scenario:
# Http client -> Transactional servlet consumer
# Servlet route calls java bean
# Java bean calls another route using Camel Proxy and direct-vm
# CamelInvocationHandler calls direct-vm route and then hangs as route is
never executed, waiting for worker
At this point it all is deadlocked and it never ends.
From what I can see the problem happens in DefaultReactiveExecutor.Worker.
>From debugging I can see there are two DefaultReactiveExecutor.Workers at the
>point of deadlock.
At point 3, Worker number 2 executes SimpleTask which waits for it to finish-
this task is to execute bean as per step 3.
Bean execution then attempts to trigger another route using Camel Proxy and
direct-vm, but because it schedules direct-vm processor to the same Worker 2
which is currently processing current task it all deadlocks.
I have confirmed above in debugging, will try to come up with simple test case
as our scenario is rather complex and involves multiple projects.
Immediately after scheduling on Worker number 2 the direct-vm processor, Worker
1 executes executeFromQueue which makes me thinking that direct-vm call has
been added to wrong Worker.
Unfortunately for us this is blocker as our solution which was working
perfectly fine with camel 2 is not working.
> Route deadlock in DefaultReactiveExecutor/Worker in transactional route which
> calls Camel Proxy bean
> ----------------------------------------------------------------------------------------------------
>
> Key: CAMEL-16927
> URL: https://issues.apache.org/jira/browse/CAMEL-16927
> Project: Camel
> Issue Type: Bug
> Components: camel-core-engine
> Affects Versions: 3.7.2
> Reporter: Piotr Klimczak
> Priority: Critical
>
> My scenario:
> # Http client -> Transactional servlet consumer
> # Servlet route calls java bean
> # Java bean calls another route using Camel Proxy and direct-vm
> # CamelInvocationHandler calls direct-vm route and then hangs as route is
> never executed, waiting for worker
> At this point it all is deadlocked and it never ends.
> From what I can see the problem happens in DefaultReactiveExecutor.Worker.
> From debugging I can see there are two DefaultReactiveExecutor.Workers at the
> point of deadlock.
> At point 3, Worker number 2 executes SimpleTask which waits for it to finish-
> this task is to execute bean as per step 3.
> Bean execution then attempts to trigger another route using Camel Proxy and
> direct-vm, but because it schedules direct-vm processor to the same Worker 2
> which is currently processing current task it all deadlocks.
> I have confirmed above in debugging, will try to come up with simple test
> case as our scenario is rather complex and involves multiple projects.
> Immediately after scheduling on Worker number 2 the direct-vm processor,
> Worker 1 executes executeFromQueue (triggered by countdownLatch waiting for
> direct-vm call to finish) which makes me thinking that direct-vm call has
> been added to wrong Worker.
> Unfortunately for us this is blocker as our solution which was working
> perfectly fine with camel 2 is not working.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
