Currently, the batch subsystem behaves like these:
- If a job is {}not stopped{} during a "server crash", then the job will always be kept in STARTED status.
- If a job is {}stopped{} during a "server crash", then the job will be moved into UNKNOWN status.
- If a {}crashed{} job stays in STARTED status and is stopped after a "server restart", the job will be moved into UNKNOWN status.
- The UNKNOWN job can’t be restarted manually in the Admin Console. (I haven't checked the CLI side)
The current implementation could be improved in these places:
- No matter whether a job is {}stopped{} or not during a "server crash", the job {}shouldn’t{} be kept in UNKNOWN status.
- The STARTED job should be able to be stopped correctly, and it {}shouldn’t{} be moved to UNKNOWN status after manually stopping it.
- clones
-
WFLY-19706 More gracefully handle the job execution status during a server crash.
- Open
- is cloned by
-
JBEAP-28048 [GSS](7.4.z) WFLY-19706 - More gracefully handle the job execution status during a server crash.
- New