![]() |
VOOZH | about |
Retry and skip logic are essential features in Spring Batch that help manage errors and exceptions during batch processing. They ensure that batch jobs can recover from failures and continue processing data without causing job failures. Here's an explanation of retry and skip logic in Spring Batch:
Spring Batch includes retry logic which lets configure and manage the number of attempts the process will attempt when encountering a non-fatal error. Non-fatal errors usually pass with a retry and tend to be temporary problems. Using retry logic in your batch processing tasks makes the jobs more robust, in that before labeling a job as a failure, an unsuccessful one is tried again. Below are steps that can be followed to implement retry logic in Spring Batch:
The first step is to identify the specific batch step where you want to implement retry logic. You typically apply retry logic to a chunk-based step, where data is read, processed, and written in chunks.
Use StepBuilderFactory to create and configure the batch step in your Spring Batch configuration. Below is an example
Where,
3. Implement Custom Retry Listeners (Optional)
If you attached a custom retry listener using listener(), you need to implement the listener as a Spring bean. A custom retry listener can be used to perform actions before and after each retry attempt. For example, you can log retry attempts or customize the behaviour:
If you want to apply retry logic specifically to exceptions thrown by your ItemProcessor, make sure your ItemProcessor is designed to throw these exceptions when necessary. Spring Batch will then catch these exceptions and apply the retry logic as configured.
With retry logic configured, you can now run your Spring Batch job. When exceptions occur during item processing, Spring Batch will automatically retry items based on your configuration. If the maximum number of retries is reached or if the retry logic determines that no more retries should be attempted, Spring Batch will proceed to the next item or take appropriate action based on your configuration.
When you want to skip problematic items after having reached some predefined number of retrial failures, this is done with the help of skip logic. These products keep failing after retry attempts, hence it is right for these services. Spring Batch does not terminate the whole process but overlooks the defected elements and continues with the rest. Below steps can be followed To implement skip logic in Spring Batch,
Below source code explains how to configure skip logic in spring batch:
Aspect | Retry logic | Skip Logic |
|---|---|---|
Objective | Retry the same operation multiple times to recover from transient errors. | Skip problematic items and continue processing with the next item. |
Configuration | It is Configured at the step level using .retry() and .retryLimit() methods. | It is Configured at the step level using .skip() and .skipLimit() methods. |
Exception Trigger | Retries are triggered when an exception of specified type(s) occurs during item processing. | Skips are triggered when the same item fails to process multiple times or when a specific exception(s) occurs. |
Number of Attempts | Retry logic allows you to specify the maximum number of retry attempts per item (e.g., .retryLimit(3)). | Skip logic allows you to specify the maximum number of items to skip (e.g., .skipLimit(10)). |
Back-off Policy | You can configure a backoff policy to introduce delays between retry attempts. (e.g., .backOffPolicy(new ExponentialBackOffPolicy())) . | Back off policies are not used in skip logic, as skipping items does not involve retrying them. |
Handling Logic | Each retry attempts results in a retry logic processing of the same item . The item fails if the maximum no. of retry is achieved. | After a certain number of retries, skip logic skips problematic items. An item that gets past the skip limit is not retried and is deemed a failure. |
Typical Use Cases | For transient errors anticipated to resolve upon retry like network timeouts. | Applicable in handling consistently problematic things that are not retry-able. This stops job failure because of a handful defects. |