-
Feature Request
-
Resolution: Fixed
-
L3 - Default
-
None
-
None
- Assign deployment ids to batch jobs
- Types: Delete Historic Instances, Set Job Retries, Set External Task Retries, Update Process Instance Suspension State; Delete Historic Decision Instances; Process Set Removal Time; Decision Set Removal Time
- We have it already for: Deleting runtime instances; Instance migration; Modification; Restart Process instances
- Seed job and monitor job currently require the batch job handler to do their job. They should either
- Run on the engine that has the batch job handler
- Avoid using the batch job handler
- Needs to be backwards-compatible and work in rolling update situations
Ideas for seed and monitor job handler:
- Monitor job handler should not need the batch job handler when it deletes a batch; at that time the batch jobs are already all gone, so they don't need to be deleted (however this is the reason the monitor job handler needs the batch job handler)
- The seed job handler needs the batch job handler by definition. We could have multiple seed jobs, one per deployment. Since the seed jobs update the batch entity, we should avoid optimistic locking exceptions. This can be done by suspending all seed jobs but one, and when a seed job is finished, it activates the next.
This is the controller panel for Smart Panels app
- is depended on by
-
CAM-11712 Expose "externalTaskIdIn" criterion in external task query to REST API
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- is related to
-
CAM-11675 Query max results limit should not be applied when creating a batch with a query
-
- Closed
-