Loading...

XML

Word

Printable

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.

is depended on by

CAM-11712 Expose "externalTaskIdIn" criterion in external task query to REST API

CAM-11713 Expose "jobIds" criterion in job query to REST API

CAM-11714 Expose "processInstanceIds" criterion in job query to REST API

is related to

CAM-11675 Query max results limit should not be applied when creating a batch with a query

All batches are deployment-aware