topic Re: Modelling an async user wait on a long running service task. in Alfresco Archive

Modelling an async user wait on a long running service task.

alistairb — Fri, 19 Apr 2013 11:12:27 GMT

Hi,I have a scenario where I have long running evaluation service task (Java Delegate) that I need to run asynchronously so that I can provide user feedback experience, i.e. a spinner in a web application, whilst waiting for the service task to complete. Having seen the parallel gateways feature, c

Re: Modelling an async user wait on a long running service task.

frederikherema1 — Fri, 19 Apr 2013 11:56:53 GMT

When you have long-running tasks executed by the job-executor, you should consider that:

Executing a service-task (or any other task) keeps a transaction open until a wait-state/process-end/async-task is reached. If you have long-running operations, make sure your DB doesn't time out.
When a jobs is running for 5 minutes, the job aquisistion-thread assumes the job-executor that was running the job, has either died or has failed. The lock of the job is removed and the job will be executed by another thread in the executor-pool. This timeout-setting can be raised, if that is required.
Long-running tasks modeled IN the activiti-process always keep a transaction open and a job-executor thread occupied. Better practice is to use a queue-signal approach where the long-runnin operation is executed outside of activiti (queued to eg. camel using a service-task, providing the neccesairy variables needed alongside). When the long-running task is completed, it should signal the execution, which has a recieve-task modeled in.

Re: Modelling an async user wait on a long running service task.

andreibica — Fri, 21 Feb 2014 15:22:23 GMT

I'm also trying to model a long operation followed by a result which must be feed into the workflow. For this I am using a Java Service Task to initiate the operation and a Java Receive Task to wait for the result. The problem that I see here is that the result of the operation may come faster then the engine is reaching the Java Receive Task. In this case if I am trying to signal the process when I receive the result I will get an exception because the process is not in waiting state.

Is there a way to avoid this problem or am I missing something?

Thanks,
Andrei

Re: Modelling an async user wait on a long running service task.

jbarrez — Tue, 25 Feb 2014 09:22:08 GMT

Hmmm I'm afraid such a problem can only be resolved by putting a queue in front of the service which checkes whether the process is in the correct state and delivers the message only if it's true.

Re: Modelling an async user wait on a long running service task.

andreibica — Tue, 25 Feb 2014 14:29:13 GMT

And this kind of checks should be done periodically?
Do I have a clue when I should do this kind of checkups so I don't need to pull them periodically?
In case that the state of the workflow is changed by a call comming from a thread from JobExecutor (e.g. because a timer has expired) then I don't have any clue when the process arrives in a wait state.
Is this correct?

Re: Modelling an async user wait on a long running service task.

jbarrez — Mon, 10 Mar 2014 09:11:49 GMT

> Do I have a clue when I should do this kind of checkups so I don't need to pull them periodically?

Use regular queue implementations (jms is a bit heavy, but something like hazelcast queue or something of Spring …)

> then I don't have any clue when the process arrives in a wait state.

True. But you can always query for the state of all your processes.

Re: Modelling an async user wait on a long running service task.

avirankatz — Tue, 04 Jul 2017 05:11:41 GMT

Frederik Heremans wrote:
When you have long-running tasks executed by the job-executor, you should consider that:

Executing a service-task (or any other task) keeps a transaction open until a wait-state/process-end/async-task is reached. If you have long-running operations, make sure your DB doesn't time out.
When a jobs is running for 5 minutes, the job aquisistion-thread assumes the job-executor that was running the job, has either died or has failed. The lock of the job is removed and the job will be executed by another thread in the executor-pool. This timeout-setting can be raised, if that is required.
Long-running tasks modeled IN the activiti-process always keep a transaction open and a job-executor thread occupied. Better practice is to use a queue-signal approach where the long-runnin operation is executed outside of activiti (queued to eg. camel using a service-task, providing the neccesairy variables needed alongside). When the long-running task is completed, it should signal the execution, which has a recieve-task modeled in.

Hi,

I'm also running a long service-task, and would like to raise the job execution timeout as Frederik Heremans suggested.

Does anyone (Fredeik?) know how to do it? I can't find any documentation for this.

Thanks,

Aviran

Re: Modelling an async user wait on a long running service task.

Anonymous — Tue, 04 Jul 2017 07:19:59 GMT

asyncExecutorSecondsToWaitOnShutdown
https://www.activiti.org/userguide/6.latest/#_async_executor_configuration

ProcessEngineConfigurationImpl.setAsyncExecutorSecondsToWaitOnShutdown

Activiti/ProcessEngineConfigurationImpl.java at master · Activiti/Activiti · GitHub

public ProcessEngineConfigurationImpl setAsyncExecutorSecondsToWaitOnShutdown(long asyncExecutorSecondsToWaitOnShutdown) {
this.asyncExecutorSecondsToWaitOnShutdown = asyncExecutorSecondsToWaitOnShutdown;
return this;
}

Re: Modelling an async user wait on a long running service task.

ksgphellow — Mon, 16 Oct 2017 10:49:39 GMT

I have a similar Question.

I would like to model a Process for a Questionnaire, so someone assigns the questionnaire, and the assignee has to fill that out. If the Questionnaire is not filled in 5 days I'll send him a reminder and so on.

Is this too longterm to model in Activiti or is that viable?

Re: Modelling an async user wait on a long running service task.

haridaniel — Tue, 10 Apr 2018 09:58:43 GMT

We are solving this by using only one service task for send and receive that is a spring @Component extending ReceiveTaskActivityBehavior. In the execute() you start your async processing storing your executionId, when finished just triggering that executionId.

(This works, but I'm not sure this is really the proper way, because Activiti doc says: don't extend ActivitiBehavior just if you know what you are doing.)