Job Retry Strategy not being triggered when doCommit fails

[melentye]

Hi,

I'm using JtaProcessEngineConfiguration in Activiti Engine 5.12 to execute a process with a java service task with async=true attribute.

Service task is executed fine (without exceptions) but due to the application logic issue, when transaction is committed in JtaTransactionInterceptor.doCommit method  a javax.transaction.RollbackException is raised and caught by JtaTransactionInterceptor (line 129 of JtaTransactionInterceptor.java in Activiti 5.12)

Because the exception is thrown in JtaTransactionInterceptor.doCommit and not in the service task, the logic to set up FailedJobListener (ExecuteJobsCmd.java lines 73-79) is not executed and I end up with an infinite loop of async job executions.

Surely the application logic that leads to the exception in the first place should be fixed, but I feel that there's a gap in Activiti retry strategy setup mechanism, in my opinion the exception during JTA transaction commit should not lead to infinite loop.

Two questions from my side:
1) Should this be considered a bug? I can create a ticket then
2) What would be a sensible tactical code fix? I was thinking of extending JtaProcessEngineConfiguration with a new command interceptor that would catch org.activiti.engine.impl.interceptor.JtaTransactionInterceptor.TransactionException and execute failed job retry set up logic similar to what we have in ExecuteJobsCmd.java. However it doesn't look like a good solution to me, a generic JtaTransactionInterceptor would have to know of the type of the command being executed.

any help would be much appreciated

thanks,
Andrey

[jbarrez]

hmmm it sure does seems like a bug if I understand you correctly.
But testing it is tricky: how can I force an exception in the .doCommit …

And secondly, how could that lead to an infinite loop? I tried to see how that would work in the code, but couldnt quite get it.

so

1) yes, most likely

2) That will be tricky to implement, as you notice yourself. But I do wonder if it is also the same for the Spring transaction and regular transaction calls … so if we can prove it with a unit test, we can start looking for a generic solution.

[melentye]

it will take me some time to come up with a distilled test case

in general situation can be reproduced with java service task uses JPA to store an entity to the database but this insert violates the unique constraints. Depending on the exact way how storing operation is realized and on JPA provider, you might get an exception during the execution of java delegate or later during the commit. With latest stable version of hibernate I get an exception on commit here (I don't do any flushes or anything like this in the logic of java delegate).

the infinite loop happens because number of retries is never decreased I guess, so JobExecutor just keeps picking up the job after a certain wait timeout.

[jbarrez]

hmmm now i understand better, and why it fails. Thanks for that

would be good if you can get a unit test for this.