Spring Batch Graceful Shutdown for Chunk Oriented Steps and Tasklet

[linsonmatrix]

@fmbenhassine I had reviewed your updated v6 example here -> https://github.com/spring-projects/spring-batch/blob/main/spring-batch-samples/src/main/java/org/springframework/batch/samples/shutdown/README.md and had few questions:

• Could you please guide me to examples to achieve the following, especially how Tasklet should be StoppableStep?

Ability to recover failed job executions
Prior to this release, if a job execution fails abruptly, it was not possible to recover it without a manual database update. This was error-prone and not consistent across different job repositories (as it required a few SQL statements for JDBC databases and some custom statements for NoSQL stores).
This release introduces a new method named recover in the JobOperator interface that allows you to recover failed job executions consistently across all job repositories.

Ability to stop all kinds of steps
As of v5.2, it is only possible to externally stop Tasklet steps through JobOperator#stop. If a custom Step implementation wants to handle external stop signals, it just can’t.

This release adds a new interface, named StoppableStep, that extends Step and which can be implemented by any step that is able to handle stop signals.

• Most of the repos are designed to have multiple Spring Batch Job beans. So how do I modify the below code so that I can start the specific job requested by the scheduler ("spring.batch.job.names")

JobExecution jobExecution = jobOperator.start(job, jobParameters);
Thread springBatchHook = new JobExecutionShutdownHook(jobExecution, jobOperator);
Runtime.getRuntime().addShutdownHook(springBatchHook);

• I saw you had given a different class for Job Restart. Practically when a job fails we are basically restarting the same application (e.g., via Autosys) so what needs to be done so that Spring Batch restarts the failed job.

JobExecution jobExecution = jobRepository.getJobExecution(1);
jobOperator.restart(jobExecution);

• Another observation is regarding the below TaskExecutor bean. Is now a requirement to support the graceful shutdown feature?

// run jobs in background threads to allow the main thread to continue
// and register shutdown hooks
@bean
public TaskExecutor batchTaskExecutor() {
ThreadPoolTaskExecutor batchTaskExecutor = new ThreadPoolTaskExecutor();
batchTaskExecutor.setCorePoolSize(1);
batchTaskExecutor.setMaxPoolSize(10); // max of 10 parallel jobs at a time
batchTaskExecutor.setThreadNamePrefix("batch-");
return batchTaskExecutor;
}

Current my spring boot spring batch application implements CommandLineRunner and I believe I could still keep it the same way accommodating all these features.

your guidance is much appreciated as always!

[fmbenhassine]

Could you please guide me to examples to achieve the following, especially how Tasklet should be StoppableStep?

Conceptually, a tasklet is at a different level of abstraction than a step, so it should NOT be a StoppableStep, it should rather be a StoppableTasklet. It is the upper-level TaskletStep that will propagate the stop signal to the underlying tasklet.

Most of the repos are designed to have multiple Spring Batch Job beans. So how do I modify the below code so that I can start the specific job requested by the scheduler ("spring.batch.job.names")

In v6, the JobOperator was redesigned to use domain objects for job operations instead of primitive types (see #4845). Therefore, you need to update the client code to get the Job reference and pass it to the job operator.

I saw you had given a different class for Job Restart. Practically when a job fails we are basically restarting the same application (e.g., via Autosys) so what needs to be done so that Spring Batch restarts the failed job.

You can use the same class, but similar to the previous point, you need to fetch the failed execution and restart it through the operator.

Another observation is regarding the below TaskExecutor bean. Is now a requirement to support the graceful shutdown feature?

Yes, the job operator should be configured with an asynchronous executor to run jobs in background threads so that the main thread can proceed and register the shutdown hook for the job execution.