topic Re: Timeout behaviour in activity processing in Alfresco Archive

Timeout behaviour in activity processing

dokmatik — Thu, 10 Nov 2011 10:42:08 GMT

Hi,in the following excerpt of our process definitionwaitState (TimerBoundaryEvent = 1second) -> Service Task 1 -> Service Task 2 (> 10 minutes)->waitStateI have been observing that our chain of service tasks are being rexecuted for three times with an intervall of about 10 minutes.I kno

Re: Timeout behaviour in activity processing

meyerd — Thu, 10 Nov 2011 14:50:15 GMT

The JobExecutor is responsible for executing the Timer associated with the first wait state.
In the default configuration Jobs are locked in the database for 5 minutes.
If executing the job (in this case performing the transaction up to the second wait state) takes longer than 5 minutes, it will be executed again.

Look at org.activiti.engine.impl.jobexecutor.JobExecutor, property lockTimeInMs

It could also be that the job fails, then it is also retired.

I would also worry about transaction timeouts.

Re: Timeout behaviour in activity processing

mljolje — Mon, 09 Dec 2013 09:23:42 GMT

We would like to extend 5 min timeout as well number of retries.
We have changed in activiti-engine.jar following fields of JobExecutor:

protected int maxJobsPerAcquisition = 0; // no retries
protected int lockTimeInMillis = 20 * 60 * 1000; // 20 min

but behaviour of activiti seems stayed as before (after 5 min retry is triggered anyway), besides we have seen that act_ru_job table contains job with lock_exp_time_ set to 20 mins as it is in code.
Do you know why is this happening?
How to increase 5 mins and set retries to 0?

Thank you.

BR
Marije

Re: Timeout behaviour in activity processing

frederikherema1 — Tue, 10 Dec 2013 12:39:20 GMT

The "maxJobsPerAcquisition" property does not influence the retry-count. In order to prevent retries, extend the org.activiti.engine.impl.jobexecutor.DefaultFailedJobCommandFactory class. Override the getCommand() and return a command that ALWAYS sets the retries to 0 (base your impl on DecrementJobRetriesCmd):


 public Object execute(CommandContext commandContext) {
 JobEntity job = Context
      .getCommandContext()
      .getJobEntityManager()
      .findJobById(jobId);
    job.setRetries(0);
    job.setLockOwner(null);
    job.setLockExpirationTime(null);

 if(exception != null) {
      job.setExceptionMessage(exception.getMessage());
      job.setExceptionStacktrace(getExceptionStacktrace());
    }
 }

Use a process-engine configuration with a JobExecutor set manually, and call the setLockTimeInMillis() with the value you need. Also, make sure that the transaction-timeout of your connection is AT LEAST as big as the lock-time you chose, otherwise the job will fail due to transaction-timeout.

This, in combination with the zero-retries-approach will fix your issue.

Re: Timeout behaviour in activity processing

mljolje — Wed, 11 Dec 2013 13:21:54 GMT

Thank you for reply.

We are using postgres database so how we can set/change connection transaction-timeout in order to avoid those timeouts?

Thanks.

BR
Marije

Re: Timeout behaviour in activity processing

jbarrez — Wed, 11 Dec 2013 14:30:32 GMT

A simple google query gave me this: http://www.postgresql.org/docs/8.3/static/runtime-config-client.html. Search for timeout there.

Re: Timeout behaviour in activity processing

mljolje — Wed, 11 Dec 2013 15:11:33 GMT

I have expected to set that transaction timeout inside activiti over some property.
Is that possible?
Thanks,
BR
Marije

Re: Timeout behaviour in activity processing

frederikherema1 — Thu, 12 Dec 2013 07:53:49 GMT

Transaction timeout depends on the Database you're on and the datasource you're using. This is nothing Aciviti can set, since it differs for all implementations. Consult the docs of the DB/Driver/datasource you're using to set the connection-timeout value. Please note that having long transaction-timeouts generally has a negative impact on overall DB performance/memory usage.

For long-lasting operations (that don't explicitly need a transaction to be open), consider using a mechanism that halts the process (e.g.. with a receive-task) and do the work externally. When finished, just signal the process using the API (possibly passing any variables that need to be set as a result of the long-running operation).

If you have a lot of long-running stuff, consider using camel and activiti for this, as camel has a lot of great stuff OOTB for this kind of use cases.

Re: Timeout behaviour in activity processing

nvulchev1 — Wed, 17 Feb 2016 14:53:45 GMT

Hi,
Is it possible to configure LockTimeInMillis on serviceTask level, but not globally for the JobExecutor? We have some async service tasks that are rather long-running and during their execution they need to read/write variables to DelegateExecution. So what is the recommended approach for this use case?

Thanks!

Re: Timeout behaviour in activity processing

martin_grofcik — Wed, 17 Feb 2016 20:38:34 GMT

Hi,

"local" setting of LockTimeInMillis is not supported. (You could implement your own JobExecutor implementation).
I would create real asynch call in your case.
1. call service start (just take the request to start the execution and return immediately)
2. wait on the message/signal from the service in the process execution to proceed further.

Regards
Martin