5.17 Async ServiceTask with later receiveTask signal not working

[njames]

Hi,
Sorry if this is a FAQ, but I haven't been able to find an answer in the forum yet.
I am updating our existing app from Activiti 5.15.1 to 5.17.0. A result of this upgrade is that I am unable to make the async-continuations work as I thought they should.

We use the following construct to have a long running service task (actually a camel route):

    <serviceTask id="longRunningTask" name="Run Camel Route" activiti:async="true" activiti:type="camel"></serviceTask>
    <sequenceFlow id="flow2" sourceRef="longRunningTask" targetRef="receiveTask"></sequenceFlow>
    <receiveTask id="receiveTask" name="Wait for confirmation of camel route finishing"></receiveTask>
‍‍‍‍‍

Then we have a Camel route

      this.from("activiti://asyncTest:longRunningTask?copyVariablesFromProperties=true")
         .routeId("asyncTest:longRunningTask")
         // Do some long running type task here!
         .log(LoggingLevel.DEBUG, "Releasing process")
         // Release the receive task now….
         .to("activiti://asyncTest:receiveTask?copyVariablesFromProperties=true");
‍‍‍‍‍‍‍‍

This worked like a charm with the older version of Activiti, but with the new version it says:

Stacktrace
—————————————————————————————————————————————
java.lang.RuntimeException: Couldn't find activity receiveTask for processId 7 in defined timeout.
   at org.activiti.camel.ActivitiProducer.signal(ActivitiProducer.java:123)
   at org.activiti.camel.ActivitiProducer.process(ActivitiProducer.java:65)
   at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
   at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:113)
‍‍‍‍‍‍‍‍‍

I have tried with the configuration recommended for using the old JobExecutor given in the release notes. When that didn't work, I used the new AsyncExecutor with similar (bad) results.

In my unit test, using 5.17.0, I find it interesting that the activityId of the processInstance is still set to longRunningTask after the startProcessInstanceByKey call. I was expecting that it would have moved to "receiveTask" before passivating.

Sorry for the rambling, I hope someone can give me a nudge in the right direction.

[trademak]

Hi Nick,

How much time is there between starting the Camel route and invoking the receive task?
Can you share a unit test showing the issue, so I can look into it?

Best regards,

[njames]

Hi Tijs,
Thanks for the quick response.
In my unit tests, I see the route started after waiting about 9 seconds. It triggers the receive task about 0.2 seconds later.
I can certainly try to make a simple unit test for this (I do need to read the sticky messages on the subject). Do I need to worry about putting it in the camel project vs the engine project tests?
Just at first look I don't see why the AsyncProcessTest in activiti-camel isn't showing the same issue.

[njames]

Hi Tijs,
I have checked out the activiti-5.17.0 branch and made a small modification to an existing unit test in the activiti-camel module.
I have removed the use of seda from src/test/java/org/activiti/camel/revisited/AsyncProcessRevisitedTest.java

     @Override
     public void configure() throws Exception {
-      from("activiti:asyncCamelProcessRevisited:serviceTaskAsync1").to("bean:sleepBean?method=sleep").to("seda:continueAsync1");
-      from("seda:continueAsync1").to("activiti:asyncCamelProcessRevisited:receive1");
+      from("activiti:asyncCamelProcessRevisited:serviceTaskAsync1").to("bean:sleepBean?method=sleep").to("activiti:asyncCamelProcessRevisited:receive1");
        
-      from("activiti:asyncCamelProcessRevisited:serviceTaskAsync2").to("bean:sleepBean?method=sleep").to("bean:sleepBean?method=sleep").to("seda:continueAsync2");   
-        from("seda:continueAsync2").to("activiti:asyncCamelProcessRevisited:receive2");
+      from("activiti:asyncCamelProcessRevisited:serviceTaskAsync2").to("bean:sleepBean?method=sleep").to("bean:sleepBean?method=sleep").to("activiti:asyncCamelProcessRevisited:receive2");
     }
    });
Instead of sending the exchange to seda endpoints and having separate routes for the seda queues, I have ended the service task routes by sending them directly to the activiti endpoint to signal the receive tasks.
When I do this, the test shows my issue.

01:04:15,654 [Thread-8] INFO  org.activiti.engine.impl.asyncexecutor.AcquireTimerJobsRunnable  - {} starting to acquire async jobs due
01:04:15,654 [Thread-9] INFO  org.activiti.engine.impl.asyncexecutor.AcquireAsyncJobsDueRunnable  - {} starting to acquire async jobs due
01:04:18,657 [main] INFO  org.activiti.engine.impl.asyncexecutor.DefaultAsyncJobExecutor  - Shutting down the default async job executor [org.activiti.engine.impl.asyncexecutor.DefaultAsyncJobExecutor].
01:04:18,659 [Thread-8] INFO  org.activiti.engine.impl.asyncexecutor.AcquireTimerJobsRunnable  - {} stopped async job due acquisition
01:04:18,659 [Thread-9] INFO  org.activiti.engine.impl.asyncexecutor.AcquireAsyncJobsDueRunnable  - {} stopped async job due acquisition
01:04:21,256 [pool-1-thread-1] ERROR org.apache.camel.processor.DefaultErrorHandler  - Failed delivery for (MessageId: ID-xx-1 on ExchangeId: ID-xx-3). Exhausted after delivery attempt: 1 caught: java.lang.RuntimeException: Couldn't find activity receive1 for processId 4 in defined timeout.
java.lang.RuntimeException: Couldn't find activity receive1 for processId 4 in defined timeout.
at org.activiti.camel.ActivitiProducer.signal(ActivitiProducer.java:123)
at org.activiti.camel.ActivitiProducer.process(ActivitiProducer.java:65)
at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
It seems very strange that we have to use asynchronous Camel via the seda component to make activiti:async="true" work for a service task.

[donovanmuller]

I've just hit this (using 6.0.0.Beta1). @njames, thanks for doing the investigation.

If this is expected behaviour, shouldn't it be added to the docs, so that others won't run into the same issue?