Hi All,
Kindly assist on my question as below. Thanks.
In my process flow, the failed service tasks did not retry by itself after encounter the below error.
"Error while evaluating expression: #{sampleService.processDocument(execution)}. Cause: org.springframework.transaction.HeuristicCompletionException: Heuristic completion: outcome state is mixed; nested exception is org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only "
Referring to the following user guide, a failed job will be retried a number of times (by default 3). So what could be the root cause? I am deploying in the Tomcat distribution for Camunda.
https://docs.camunda.org/manual/7.4/user-guide/process-engine/the-job-executor/#failed-jobs
Hi,
Can you please check the database table ACT_RU_JOB? It should contain an entry for the job in question and the RETRIES_ column should show if the job has any retries left (if > 0) or not. Please post the row here.
Cheers,
Thorben
Hi,
The RETRIES_ value is 0.
ID_ REV_ TYPE_ LOCK_EXP_TIME_ LOCK_OWNER_ EXCLUSIVE_ EXECUTION_ID_ PROCESS_INSTANCE_ID_ PROCESS_DEF_ID_ PROCESS_DEF_KEY_ RETRIES_ EXCEPTION_STACK_ID_ EXCEPTION_MSG_ DUEDATE_ REPEAT_ HANDLER_TYPE_ HANDLER_CFG_ DEPLOYMENT_ID_ SUSPENSION_STATE_ JOB_DEF_ID_
------------------------------------ ------- -------- ----------------- -------------- ------------- ------------------------------------ ------------------------------------ ------------------------------------------------------ ------------------- ----------- ------------------------------------ --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ----------- ---------- ------------------ --------------------------------------- ------------------------------------ -------------------- ------------------------------------
7ea92ad5-f163-11e5-ba06-52540098440e 7 message (null) (null) 1 7ea903b5-f163-11e5-ba06-52540098440e 7ea903b5-f163-11e5-ba06-52540098440e sampleProcess:2:646ab70e-f0da-11e5-987d-52540098440e sampleProcess 0 7ede4499-f163-11e5-ba06-52540098440e Error while evaluating expression: #{sampleService.processDocument(execution)}. Cause: org.springframework.transaction.HeuristicCompletionException: Heuristic completion: outcome state is mixed; nested exception is org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only (null) (null) async-continuation transition-create-scope$SequenceFlow_11 642c7562-f0da-11e5-987d-52540098440e 1 646ab70f-f0da-11e5-987d-52540098440e
848f7b66-f163-11e5-ba06-52540098440e 7 message (null) (null) 1 848f5446-f163-11e5-ba06-52540098440e 848f5446-f163-11e5-ba06-52540098440e sampleProcess:2:646ab70e-f0da-11e5-987d-52540098440e sampleProcess 0 84b6645a-f163-11e5-ba06-52540098440e Error while evaluating expression: #{sampleService.processDocument(execution)}. Cause: org.springframework.transaction.HeuristicCompletionException: Heuristic completion: outcome state is mixed; nested exception is org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only (null) (null) async-continuation transition-create-scope$SequenceFlow_11 642c7562-f0da-11e5-987d-52540098440e 1 646ab70f-f0da-11e5-987d-52540098440e
Hi,
I assume the process engine then retried the job already three times, unless you have a different configuration. To check that, you can have a look at the table ACT_HI_JOB_LOG. It contains entries for when a job was created (field JOB_STATE_ has value 0), executed (successfully (value 2) or with a failure (value 1)) and deleted (value 3). You will only find these entries if the process engine uses history level full which is the default for the the pre-built Camunda distributions.
Cheers,
Thorben
Hi,
I don’t see table name ACT_HI_JOB_LOG, so I think it is not been enabled. How do I enable it, and how do I enable the retry by default for all failed service? Thanks.
p/s: The reason i said the job is not been retry is because i can track from the logging.
Hi,
If you are using the pre-built Camunda Tomcat distribution that you can download on camunda.org, the table itself should be there. What I meant is that it is empty, if history level is not full. Did you set up the database schema yourself using Camunda’s SQL create scripts or was it automatically set up by Camunda? It may also be helpful to share the process engine configuration that you use.
For the default of three retries per service task, you don’t have to reconfigure anything. There is a process engine configuration setting defaultNumberOfRetries that you can set to any number >= 0 to override the setting of 3.
Cheers,
Thorben
Hi,
I recreate the db using the SQL create scripts. Ya, i don’t see ACT_HI_JOB_LOG table in the scripts.
Attached with the configuration file which should be the default one. Should I set the defaultNumberOfRetries value in order to “re-activate” back the retry mechanism? Please advise, thanks a lot.
bpm-platform.xml (3.4 KB)
Hi,
Which create scripts did you use? When I download the Camunda BPM 7.4.0 Tomcat distribution, then there is a file sql/h2_engine_7.4.0.sql that contains DDL statements for the history tables, ACT_HI_JOB_LOG being among them. I will be surprised if the process engine with history level full does not throw any exception when the history tables aren’t there, so I suspect some inconsistency in your setup. How is the datasource java:jdbc/ProcessEngine defined?
You can set a job’s retries by using the Java API ManagementService#setJobRetries or via REST API.
Edit: Do you declare an additional process engine in your application?
Cheers,
Thorben
Hi,
I am still using version 7.2.0, the mysql sql create script do not have the ACT_HI_JOB_LOG table. In term of development, i am using grails with camunda plugins to create the workflow process and then deploy the war file into camunda tomcat dist.
Here is the data source definition:
H,
Ah, sorry, I assumed you use 7.4. 7.2 indeed does not have the job log so we can’t use that to check what is going on.
Can you share a minimal project and the steps that reproduce the problem?
Cheers,
Thorben
Hi,
After added the defaultNumberOfRetries into the configuration file, the failed job did retry for a number of times as configured. So I assume my problem is fixed. Thanks a lot for your help.
The next steps should be upgrading the camunda version.