cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with simple process

fwachs
Champ in-the-making
Champ in-the-making
Hi all,

I'm having a hard time with a really simple process.
It's got a timer start event, then the process runs perfectly. The problem is that once it's done .. it runs it again! and again and again.

[img]https://s3.amazonaws.com/zukbox-test/resources/problem2.png[/img]

What could be causing this problem? It's the only timer start event that has this problem, all of the others are working perfectly.

Thanks,
Federico
15 REPLIES 15

fwachs
Champ in-the-making
Champ in-the-making
Okay, does the job succeed or does it run into an error (OptimisticLockingException for example)?
How long does the job need to execute? Is it only starting a process instance and executing a few automatic service tasks that run very quickly? Or does starting the process instance take very long (> 30 seconds) ?

Best regards,

The job sometimes succeds sometimes it throws OptimisticLockingException, The job could take from 1 to 15 minutes the most, depending on how many emails it needs to send. I've modified MailActivityBehavior to not fail under any circumstance, the process is the same you are seeing up here in this thread, just a few service tasks whi ch only hit the database for a query that takes no time and never fails, then starts sending emails and emails …

trademak
Star Contributor
Star Contributor
Okay then I understand. While the process is sending the e-mails, the transaction is not committed yet.
Because we have a default job lock interval of 5 minutes, if a job takes longer than 5 minutes, the job executor will try the same job again because it expects that something went wrong.
If you can't refactor the process to keep the execution under 5 minutes, the best way to go forward is to increase the lockTimeInMillis to some value in which the job is definitely executed.
Although my advice would be to reduce the synchronous job execution time if possible using for example async handling.

Best regards,

fwachs
Champ in-the-making
Champ in-the-making
Okay then I understand. While the process is sending the e-mails, the transaction is not committed yet.
Because we have a default job lock interval of 5 minutes, if a job takes longer than 5 minutes, the job executor will try the same job again because it expects that something went wrong.
If you can't refactor the process to keep the execution under 5 minutes, the best way to go forward is to increase the lockTimeInMillis to some value in which the job is definitely executed.
Although my advice would be to reduce the synchronous job execution time if possible using for example async handling.

Best regards,
So what you are saying is I should modify either this on the code protected int lockTimeInMillis = 5 * 60 * 1000; in JobExecutor.java
or change my process to support asynchronous execution. I believe that, for me, it's best to change both actually, right?


Setting my subproces as asynchronous and exlusive to false would be an improvement as well?
Thanks

jbarrez
Star Contributor
Star Contributor
o what you are saying is I should modify either this on the code protected int lockTimeInMillis = 5 * 60 * 1000; in JobExecutor.java
or change my process to support asynchronous execution. I believe that, for me, it's best to change both actually, right?

There is a setter for the lockTimeMillis on the JobExecutor. Retrieve the job executor by casting the process engine to ProcessEngineImpl and set the timing accordingly.

Alternatively (and maybe cleaner) you can inject your own JobExecutor impl (extending the default one) on the ProcessEngineCOnfiguration (ie in your activiti.cfg.xml).

fwachs
Champ in-the-making
Champ in-the-making
o what you are saying is I should modify either this on the code protected int lockTimeInMillis = 5 * 60 * 1000; in JobExecutor.java
or change my process to support asynchronous execution. I believe that, for me, it's best to change both actually, right?

There is a setter for the lockTimeMillis on the JobExecutor. Retrieve the job executor by casting the process engine to ProcessEngineImpl and set the timing accordingly.

Alternatively (and maybe cleaner) you can inject your own JobExecutor impl (extending the default one) on the ProcessEngineCOnfiguration (ie in your activiti.cfg.xml).
Sounds good, I'll do that then! What do you think about changing asynchronous (to true) and exclusive ( to false) to the subprocess ?

jbarrez
Star Contributor
Star Contributor
What do you think about changing asynchronous (to true) and exclusive ( to false) to the subprocess ?

That is an option, but you would also increase the risk for an optimistic locking exception.