Timeout behaviour in activity processing

[dokmatik]

Hi,

in the following excerpt of our process definition

waitState (TimerBoundaryEvent = 1second) -> Service Task 1 -> Service Task 2 (> 10 minutes)->waitState

I have been observing that our chain of service tasks are being rexecuted for three times with an intervall of about 10 minutes.

I know there is a retry feature which defaults to 3 retries.
But I thought retries are only executed in case of exceptions.

Since we have a very long running service task I assume due to to some timeout feature in Activiti
our chains gets rescheduled.

Could you please clarify ?

Regards
dokmatik

[meyerd]

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.

[mljolje]

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

[frederikherema1]

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.

[mljolje]

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

[jbarrez]

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

[mljolje]

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

[frederikherema1]

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.

[nvulchev1]

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!

[martin_grofcik]

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