My config is as follows (leaving out irrelevant info) @Bean(destroyMethod = “destroy”)
public ProcessEngineFactoryBean processEngine(ManagedAsyncJobExecutor asyncJobExecutor) {
final SpringProcessEngineConfiguration spec = new SpringProcessEngineConfiguration();
spec.setFlowable5CompatibilityEnabled(true);
spec.setFlowable5CompatibilityHandlerFactory(springFlowable5CompatibilityHandlerFactory());
spec.setAsyncExecutorActivate(configuration.isAsyncExecutorActivate());
spec.setAsyncExecutor(asyncJobExecutor);
ProcessEngineFactoryBean factoryBean = new ProcessEngineFactoryBean();
factoryBean.setProcessEngineConfiguration(spec);
return factoryBean;
}
@Bean
public ManagedAsyncJobExecutor asyncJobExecutor(ExecutorService executorService) {
ManagedAsyncJobExecutor jobExecutor = new ManagedAsyncJobExecutor();
jobExecutor.setExecutorService(executorService);
jobExecutor.setDefaultAsyncJobAcquireWaitTimeInMillis(1000);
jobExecutor.setDefaultTimerJobAcquireWaitTimeInMillis(1000);
return jobExecutor;
}
@Bean
public ExecutorService executorService() {
return Executors.newCachedThreadPool();
}
The behaviour of a flowable5 process seems to be different though compared to when the process is executed by the flowable6 engine. This happens when executing a JavaDelegate that is both set to async and exclusive. The job is locked for 60 seconds in compatibility mode before executing, while this does not happen in flowable 6 engine that executes after the wait time.
While we do not have any cases where we actively use the exclusive flag, this does not matter much, also the delegate is executed after the timeout, but I wanted to report this here and also ask if this is the expected behaviour?
The behavior should be the same, as the v5 engine simply hands it off to the v6 engine, so the 60 seconds is odd (is it always exactly 60 seconds? Or does it vary?). Is there anything specific about your process definition? Can you post the relevant definition snippet?
The only thing specific is that the JavaDelegate is set to async and exclusive. I tried replicating the behaviour with a unit test, but I failed to reproduce it. I kept the implementation of the AsyncExecutor the same (DefaultAsyncJobExecutor).
One thing that seems to differ is the following: on my running server, it seems that the async job is placed in the job table, and the lockTime is set in ExecutionEntityManager#updateProcessInstanceLockTime(String processInstanceId). This happens in both scenario’s.
But after that things differ: on my server, the job is picked up in AcquireAsyncJobsDueRunnable and finally the asyncExecutor will execute it. In contract, my unit test seems to continue always immediately when passing ExecuteAsyncRunnable#isHandledByV5Engine().
It seems to me that the behaviour of async is vastly different compared to the unit test, which makes me think that this is just a configuration error on my part. However, I have yet to discover why it behaves differently on flowable 6 (once I redeploy the process).
Thanks for posting the unit test. At first glance, the unit tests seems to be okay. In fact, the async executor is booted up in the regular way (the way it’s used for real) and not in a unit-test way. So that’s all good.
Not sure what’s going on that would explain the 1 minute delay (although it’s too round of a number to be coincidence)… so not sure where to look next … if you find any bit of information extra, please post here.
