Need help to retrive the process variables after JVM restart

[lakmg]

Hi,

We have a scenario where we have two service task and we store few process variables into activiti DB during service task execution.
We need to retrive this process variables after JVM restart. Is there any way we can achieve this?

Thanks,
Lakshmi

[frederikherema1]

When the process reaches a wait-state (user-task, recieve-task, …) OR an asynchronous execution OR a process-end, the process-variables are stored in the database. All operations done from the API-invokation (eg. start process, compete task) until the wait-state/async/end are done in a single transaction. In case the JVM crashes in while the service-tasks are executing, the transaction will be rolled-back to the start it was before the API-call was done. So there won't be any trace of the execution that was going on when the JVM went down.

[lakmg]

Hi,

We have a below mentioned scenario.

UserTask - UT
ServiceTask - ST

UT1 –> ST1–> ST2–> ST3–> UT2–> ST4–>ST5–> UT3

While the execution is in progress and say for example if the current execution is at ST2, and if our process/JVM goes for a restart, once it comes back, we want the execution to continue from where it left.

We tried making the Async status to true and with this, activiti is actually continuing the task from where it left after the restart.

Could you please let us know if there is any drawback with this approach to achieve what we are looking at?

Regards,
Lakshmi

[frederikherema1]

If you make all service-tasks async, they will indeed be running in a separate transaction and a failure (or JVM-crash) will only rollback the last one.

The only drawback there is to this (and this is not a real drawback, just a fact) that the startProcess() or completeTask() call will return immediately when it reaches the first async-service-task. You know the service-task is now going to be executed ion the background, but don't get any exceptions in the calling thread that does the API-call. If a service-task fails, the exception is present in the corresponding job-entity. In case of NONE of the service-tasks are asynchronous, when the completeTask() method returns without exceptions, you can be sure all service-tasks were executed without issues… So this requires some more logic/admin work to see if the process is still moving on without exceptions in the background.

[lakmg]

Thanks for your input. One more quick question on this.

With that above scenario, we made the service tasks to be async true. One thing we noticed during testing is, if any of the service tasks execution takes more than 5 minutes, then it is getting retried again.

To avoid this, updating our activiti-context file with the following bean and passing the reference as mentioned below,

could you please let us know if this is a correct way to do it and if there is any impact because of this changes. we are using activiti engine 5.8.

<bean id="myJobExecutor" class="org.activiti.engine.impl.jobexecutor.JobExecutor">
<property name="lockTimeInMillis" value="3600000"/>
</bean>

<bean id="processEngineConfiguration" class="org.activiti.spring.SpringProcessEngineConfiguration">
…
…
<property name="myJobExecutor" ref="myJobExecutor" />
…
…
</bean>

Regards,
Lakshmi

[frederikherema1]

That is indeed the correct way to raise the lock-timeout incase a service-call takes a long time. Keep in mind, however, that the service-task execution keeps a transaction active during execution and can have an impart on the DB if many open transactions are alive (+ make sure connection-timeout is set high enough). Also, if the service-task only requires little data read/write from activiti, you might consider offloading the actual execution outside of activiti (camel, for example) and use some kind of queuing-mechanism combined with signal-tasks in the process. This way, no transactions will be open for a long time and also frees up additional job-executor threads that are otherwise used for long-running executions and may impact other jobs (eg. timer-execution).

[lakmg]

Hi,

For the above mentioned scenario, i have made the jobexecutor configuration as below

<bean id="jobExecutor" class="org.activiti.engine.impl.jobexecutor.JobExecutor">
<property name="lockTimeInMillis" value="7200000"/>
</bean>

<bean id="processEngineConfiguration" class="org.activiti.spring.SpringProcessEngineConfiguration">
…
…
<property name="jobExecutor" ref="jobExecutor" />
…
…
</bean>

what i observe is, since the service tasks are mentioned as async, once the JVM is restarted, the service tasks operation resumes from the last operation, whereas the delay of how much time it takes to resume the operation after JVM restart is not predictable. At times i used to see the operation getting started rightaway and at times it takes few minutes, and once i saw that the operation is taking 2 hours for it to continue. Is this anything related to lockTimeInMillis parameter? Could you please provide some details about it?

Thanks,

Regards,
Lakshmi

[ronald_van_kuij]

Well, if you specify 120 minutes the job will not be retried within 120 minutes after starting it. How long that is after restarting the server is dependend on at what point in time between job creation and lock timeout you restarted the server. That is at least what I know from the jobexecutor.

[lakmg]

Thanks Ronald for the info.

Without specifying the lockTimeInMillis, by default if any service tasks takes more than 5 mins, then the service task was getting retried again.

Hence we tried to change this timer to 2 hours (assuming some of the service task we have might take more time). But changing this value to 2 hours, now we are observing the behavior stated in the last post.

Regards,
Lakshmi

[lakmg]

So increasing the lockTimeInMillis would have an impact on the service task startup after the JVM restart? I mean increasing this value would delay the start of the service task execution after restart, is that observation correct? could you please confirm.

Regards,
Lakshmi