Details
-
Bug Report
-
Resolution: Unresolved
-
L3 - Default
-
None
-
None
-
None
-
None
Description
Environment (Required on creation):
Any
Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):
The user wants to suspends the history cleanup (ever-living) jobs. However, the action is ignored and the jobs are activated automatically during the rescheduling of the jobs
Steps to reproduce (Required on creation):
- Configure History cleanup batch window with degree of parallelism 1 (strategy doesn't matter) and start the engine
- During the execution of the history cleanup before the History cleanup rescheduling, suspend the ever-living job via REST API
Observed Behavior (Required on creation):
The ever-living job is activated again during the rescheduling of the job
Expected behavior (Required on creation):
The suspension state of the job is considered during the rescheduling of the job, the job is not activated.
Root Cause (Required on prioritization):
During the rescheduling of the history cleanup job where the due date of the cleanup job is updated is performed the following. The cleanup job is selected from the database, and the suspension state is set to ACTIVE:
- Call to reschedule the job: https://github.com/camunda/camunda-bpm-platform/blob/master/engine/src/main/java/org/camunda/bpm/engine/impl/jobexecutor/historycleanup/HistoryCleanupSchedulerCmd.java#L62
- Activate job: https://github.com/camunda/camunda-bpm-platform/blob/master/engine/src/main/java/org/camunda/bpm/engine/impl/persistence/entity/JobManager.java#L120
Solution Ideas (Optional):
Hints (Optional):
- In case both actions, the suspension of the job via REST API and the job reschedule are done concurrently. This leads an OptimisitcLockingException, and one of the transactions is rolled back. It can happen that the transaction of the rescheduler is rolled back, which means that the history cleanup job stays suspended and the history cleanup job is paused.