cancel
Showing results for 
Search instead for 
Did you mean: 

Async service tasks fails to update status

paulfrancis
Champ in-the-making
Champ in-the-making
I executed an activiti model, made up of 13 asynchronous non exclusive java service tasks, all in parallel to one another, and all linked to a single start and end event.

When the workflow starts, all the 13 service tasks gets instantiated, and the task execution completes successfully for all 13 on the back end (python scripts which produces 13 different images) , however when checked the activiti database, it shows only 5 of them were completed successfully and the rest of 8 scheduled for retry.

When retry happens all 8 remaining tasks are  re-executed successfully in the back end (produced 8 images), but again activiti counts only 4 of them completed successfully and the rest  4 scheduled for retry. The final retry executes all four both in the front and back end.

there is a total of 25 executions instead of 13.

I cannot explain this behavior of activiti, such as even though the java delegate class executes successfully in parallel, its not registering the exit of some of the async-non-exclusive tasks.

Please help me out in understanding this strange behavior.


3 REPLIES 3

martin_grofcik
Confirmed Champ
Confirmed Champ
What was the reason for retry?
(Any stack trace?)

Regards
Martin

paulfrancis
Champ in-the-making
Champ in-the-making
This the message in catalina.out

Exception in thread "pool-2-thread-4" org.activiti.engine.ActivitiOptimisticLockingException: ProcessInstance[1627] was updated by another transaction concurrently
at org.activiti.engine.impl.db.DbSqlSession.flushUpdates(DbSqlSession.java:562)
at org.activiti.engine.impl.db.DbSqlSession.flush(DbSqlSession.java:444)
at org.activiti.engine.impl.interceptor.CommandContext.flushSessions(CommandContext.java:170)
at org.activiti.engine.impl.interceptor.CommandContext.close(CommandContext.java:117)
at org.activiti.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:66)
at org.activiti.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:47)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)
at org.activiti.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:45)
at org.activiti.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:31)
at org.activiti.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:40)
at org.activiti.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:35)
at org.activiti.engine.impl.jobexecutor.ExecuteJobsRunnable.run(ExecuteJobsRunnable.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

martin_grofcik
Confirmed Champ
Confirmed Champ
Hi Paul,

It seems that process instance is updated concurrently from different threads. How to avoid it: you can try to set org.activiti.engine.impl.interceptor.CommandConfig#contextReusePossible to false. I am not sure - I did not test it but may be it could help.
If not prepare jUnit test for it.

Regards
Martin