skip to content

Explain the difference between JobOperator.stop and JobOperator.abandon, including the semantics of a stop request.

level: seniorimportance: must knowfreq 48%

answer

  1. stop = cooperative, sets STOPPING/terminateOnly
  2. boolean = signal sent, not job stopped
  3. Checked at chunk boundaries → JobInterruptedException → STOPPED
  4. abandon = mark non-running exec ABANDONED, skipped on restart
  5. Can't abandon a running execution

basics

~20 s

stop asks a running execution to halt gracefully — it sets the status to STOPPING and the job stops at the next safe point, ending STOPPED. abandon marks a non-running execution as ABANDONED so it's skipped on restart. stop is cooperative, not a kill.

solid answer

~50 s

stop(executionId) is a cooperative request, not a forced kill. It flags the JobExecution as STOPPING; the running step checks for that signal between chunk commits (via isTerminateOnly) and unwinds by throwing JobInterruptedException, leaving the execution STOPPED and restartable. It returns a boolean meaning 'the stop message was delivered', not 'the job has stopped'. If a step is blocked inside a single long read/process, it won't stop until control returns to the framework. abandon(executionId) is different: it targets a *non-running* execution and marks it ABANDONED, which excludes it from restart consideration. You typically abandon an execution that is already STOPPED or FAILED and that you never want restarted, or a STARTED execution orphaned by a crashed JVM. You cannot abandon a currently running execution — that throws JobExecutionAlreadyRunningException. So: stop is for live jobs; abandon is for dead/finished ones.

code

java · 12 lines
java
// Ask a running execution to stop (cooperative)
boolean signalSent = jobOperator.stop(executionId);
// signalSent == true means the STOP flag was set, NOT that the job has halted.

// Later: a crashed JVM left execution 42 stuck in STARTED and un-restartable.
// Mark it dead so the instance can be restarted:
JobExecution abandoned = jobOperator.abandon(42L); // status -> ABANDONED

// A custom long-running tasklet/step should cooperate with stop:
// if (chunkContext.getStepContext().getStepExecution().isTerminateOnly()) {
//     throw new JobInterruptedException("stop requested");
// }

go deeper

for a junior

Knows stop = graceful cancel, abandon = mark it dead.

for a middle

Explains STOPPING flag, chunk-boundary check, and STOPPED-is-restartable.

for a senior

Details cooperative semantics, boolean meaning, orphaned-STARTED recovery via abandon, and the not-running constraint.

for a principal

Designs operational runbooks: stop-then-abandon for stuck jobs, cooperative isTerminateOnly checks in custom steps, ABANDONED's effect on restart policy.

**stop — cooperative cancellation.** `boolean stop(long executionId)` does not interrupt threads or kill the process. It records intent: the `JobExecution` (and its running `StepExecution`) is marked `STOPPING` / `terminateOnly = true` in the `JobRepository`. Chunk-oriented steps check this flag at safe points — after each chunk's transaction commits, the step calls something equivalent to `stepExecution.isTerminateOnly()` and, if set, throws `JobInterruptedException`. The step and job then wind down to status `STOPPED`. Because a STOPPED job stopped at a chunk boundary with its metadata intact, it is normally *restartable* from where it left off. Key nuances: - The `boolean` return means *the stop signal was successfully sent*, not that the job is now stopped. Stopping is asynchronous. - If a step is stuck inside a single item — a huge read, a slow remote call, an infinite loop in `process` — the framework never regains control to observe the flag, so `stop` appears to do nothing until that item finishes. Custom long-running logic can poll `chunkContext.getStepContext().getStepExecution().isTerminateOnly()` to cooperate. - Throws `NoSuchJobExecutionException` if the id is unknown and `JobExecutionNotRunningException` if that execution isn't actually running. **abandon — retire a dead execution.** `JobExecution abandon(long executionId)` sets an execution's status to `ABANDONED`. Its purpose is metadata hygiene and unblocking restart: - ABANDONED executions are *ignored* when Spring Batch decides whether/how to restart a `JobInstance`. - The classic use case: a JVM crashed mid-run, leaving a `JobExecution` stuck in `STARTED`. On restart, Batch would refuse because it thinks that execution is still running (`JobExecutionAlreadyRunningException`). You cannot restart the instance while a STARTED execution lingers. Abandoning that stale execution marks it dead so a new execution can proceed. - You may also abandon a `STOPPED`/`FAILED` execution you've decided never to resume, so it won't be picked up by a restart. Constraint: `abandon` only works on executions that are **not running**. Trying to abandon a genuinely running one throws `JobExecutionAlreadyRunningException`. So the intended sequence for a stuck live job is: `stop` first; if it won't stop (e.g., the process is truly gone), then treat the orphaned execution as non-running and `abandon` it. **Status cheat-sheet.** - `stop` on running → STOPPING → STOPPED (restartable). - `abandon` on not-running → ABANDONED (excluded from restart). - FAILED → restartable by default; ABANDONED → not considered. **When to use which.** - Operator wants to cancel an in-flight run cleanly → `stop`. - Operator needs to clear an orphaned/STARTED-but-dead execution so the instance can be restarted, or permanently retire a failed/stopped one → `abandon`. **Gotcha recap.** Candidates often think `stop` force-kills threads (it doesn't) and that `abandon` can cancel a live job (it can't). Both are wrong.

  • What does the boolean returned by stop() actually mean?
    That the stop signal was successfully delivered/recorded — not that the job has already halted. Stopping is asynchronous and happens at the next safe point.
  • Why might a stop request appear to do nothing?
    The step is blocked inside a single long-running item (huge read, slow remote call, tight loop) so the framework never reaches a chunk boundary to observe terminateOnly.
  • Can you abandon a currently running execution?
    No — abandon requires a non-running execution; on a running one it throws JobExecutionAlreadyRunningException. Stop it first, or abandon only once it's confirmed dead/orphaned.

saying these in an interview costs you the question

  • Claiming stop force-kills the thread or process
  • Thinking the boolean return means the job has stopped
  • Believing abandon can cancel a live/running execution
  • Assuming a STOPPED job cannot be restarted

context

resolving links…