# Zombie Processes With Parallel Async Service Tasks **URL:** \ **Category:** Flowable Engine\ **Created:** [January 9, 2026, 12:12am UTC](https://forum.flowable.org/t/zombie-processes-with-parallel-async-service-tasks/12520 "2026-01-09T00:12:23Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![chaserb](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/chaserb/32/3084_2.png) [@chaserb](https://forum.flowable.org/u/chaserb)\ **Post date:** [January 9, 2026, 12:12am UTC](https://forum.flowable.org/t/zombie-processes-with-parallel-async-service-tasks/12520/1 "2026-01-09T00:12:23Z")
Hello, We’re encountering a very reproducible problem with asynchronous service tasks (event registry “send-event”) executed in parallel. I’ve assembled a minimal facsimile of the problem here: [GitHub - chaserb/parallel-async-service-tasks: Demonstration of zombie process instances](https://github.com/chaserb/parallel-async-service-tasks) . The problem is that about 40-50% of the time, my process instance winds up in a zombie state in that it has a single record in the ACT\_RU\_EXECUTION table with a null ACT\_ID\_, PARENT\_ID\_, and SUPER\_EXEC\_ even though all the service tasks complete successfully. I noticed a similar problem here: [ParallelGateway - Process Instance remains after all sub-processes complete](https://forum.flowable.org/t/parallelgateway-process-instance-remains-after-all-sub-processes-complete/2821) , but I’m positive our async executor is running normally. I also tried the various serviceTask options suggested here: [ParallelGateway - Process Instance remains after all sub-processes complete - #2 by adymlincoln](https://forum.flowable.org/t/parallelgateway-process-instance-remains-after-all-sub-processes-complete/2821/2) , but they did not help the situation. Thanks for your help, Chase ---
**Author:** ![chaserb](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/chaserb/32/3084_2.png) [@chaserb](https://forum.flowable.org/u/chaserb)\ **Post date:** [January 12, 2026, 2:48am UTC](https://forum.flowable.org/t/zombie-processes-with-parallel-async-service-tasks/12520/2 "2026-01-12T02:48:41Z")
LET’S HOLD OFF ON THIS FOR A BIT. I don’t think this is demonstrating what I intended. Let me work it a little more. ---
**Author:** ![chaserb](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/chaserb/32/3084_2.png) [@chaserb](https://forum.flowable.org/u/chaserb)\ **Post date:** [January 12, 2026, 7:41pm UTC](https://forum.flowable.org/t/zombie-processes-with-parallel-async-service-tasks/12520/3 "2026-01-12T19:41:45Z")
I think I’m on to the solution here. I noticed I was getting FlowableOptimisticLockingException when my parent process had an explicitly declared parallelGateway on the join side, so I updated my TestInboundChannel to catch FlowableOptimisticLockingException and retry the event which I believe (am hoping 😀) simulates the NACKs back to the Rabbit Message Broker that should be performed by the production event registry…I’ll test that. I think the real issue is that my original process definition had implicit join gateways, which was what produced the zombie process instances described above. Having explicit parallel gateways with retry on FlowableOptimisticLockingException causes my tests to pass in the example repo. ---
**Author:** ![joram](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/joram/32/26_2.png) [@joram](https://forum.flowable.org/u/joram)\ **Post date:** [January 12, 2026, 9:10pm UTC](https://forum.flowable.org/t/zombie-processes-with-parallel-async-service-tasks/12520/4 "2026-01-12T21:10:23Z")
> [@chaserb](#): > > I think the real issue is that my original process definition had implicit join gateways, which was what produced the zombie process instances described above. I haven’t looked at the example, but in that situation, I would expect a deadletter job for the joining gateway. Did you see that? ---
**Author:** ![chaserb](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/chaserb/32/3084_2.png) [@chaserb](https://forum.flowable.org/u/chaserb)\ **Post date:** [January 12, 2026, 9:47pm UTC](https://forum.flowable.org/t/zombie-processes-with-parallel-async-service-tasks/12520/5 "2026-01-12T21:47:41Z")
No, I don’t have any records in the dead letter job table for those process instances. ---
**Author:** ![joram](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/joram/32/26_2.png) [@joram](https://forum.flowable.org/u/joram)\ **Post date:** [January 13, 2026, 10:42am UTC](https://forum.flowable.org/t/zombie-processes-with-parallel-async-service-tasks/12520/6 "2026-01-13T10:42:39Z")
I had a quick look at the code and had following question: - You’re executing the jobs yourself through managementService.executeJob. Is there a reason for not wanting to use the async executor (as there are some extra pieces of logic that happen when doing so) - What’s the purpose of making the send task a wait state (i.e. triggerable)? Not sure I’m getting the use case here yet. ---
**Author:** ![chaserb](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/chaserb/32/3084_2.png) [@chaserb](https://forum.flowable.org/u/chaserb)\ **Post date:** [January 13, 2026, 2:03pm UTC](https://forum.flowable.org/t/zombie-processes-with-parallel-async-service-tasks/12520/7 "2026-01-13T14:03:40Z")
Sorry, I could have been more clear. Thanks for your quick reply. Regarding the triggerable flag, we use that to implement the Request-Reply pattern with async callback, using the execution ID as the correlation ID. For example, one of our serviceTasks will dispatch a “send email request” event to our service that accomplishes this, and then check the success of that request on the “send email response” event. Regarding the managementService.executeJob(), my only intent was to ensure the test was truly multi-threaded to simulate multiple cluster nodes receiving responses nearly simultaneously. I didn’t realize the async executor was an option in a test setup. I can give that a try. Thanks, Chase ---
**Author:** ![chaserb](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/chaserb/32/3084_2.png) [@chaserb](https://forum.flowable.org/u/chaserb)\ **Post date:** [January 13, 2026, 9:05pm UTC](https://forum.flowable.org/t/zombie-processes-with-parallel-async-service-tasks/12520/8 "2026-01-13T21:05:36Z")
A question I have regarding this relates to the async executor which we have configured with the default number of retries at 3 retries. Will the event registry “response” events benefit from this setting? Reason I ask is that the request events are dispatched on threads named “task-123”, but the response events are received on threads named “org.flowable.eventregistry.rabbit.ChannelRabbitListenerEndpointContainer#workflowInbound-1” ---
**Author:** ![joram](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/joram/32/26_2.png) [@joram](https://forum.flowable.org/u/joram)\ **Post date:** [January 14, 2026, 9:51am UTC](https://forum.flowable.org/t/zombie-processes-with-parallel-async-service-tasks/12520/9 "2026-01-14T09:51:08Z")
If your send task is async (which it is), then the sending will be done by the async executor. On the receival side, you would also need to make the first step async, or it will be run on the thread of the receiver. It’s the same story as e.g. a web request - it’ll be handled by the web container thread, unless you make a step async. ---
**Author:** ![chaserb](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/chaserb/32/3084_2.png) [@chaserb](https://forum.flowable.org/u/chaserb)\ **Post date:** [January 15, 2026, 9:21pm UTC](https://forum.flowable.org/t/zombie-processes-with-parallel-async-service-tasks/12520/10 "2026-01-15T21:21:13Z")
Let me rephrase what you said just so I’m sure I understand. I currently have this in the child process: - (startEvent) → [serviceTask (async=true)] → (endEvent) To incorporate the async executor on the receival side, I would need to make the first step async, which in the case above becomes the following: - (startEvent) → [serviceTask (async=true)] → (endEvent (async=true)) Is that correct? Thanks again, Chase ---
**Author:** ![joram](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.flowable.org/joram/32/26_2.png) [@joram](https://forum.flowable.org/u/joram)\ **Post date:** [January 16, 2026, 1:21pm UTC](https://forum.flowable.org/t/zombie-processes-with-parallel-async-service-tasks/12520/11 "2026-01-16T13:21:33Z")
> [@chaserb](#): > > Is that correct? Yes - you mention above you’re using rabbitMQ, right? This means that the receival will be handled on the rabbitMQ thread and making the step async will then hand-off to the async executor, freeing up the rabbitMQ thread.