|
[
Permlink
| « Hide
]
Dave Syer added a comment - 31/Dec/07 07:45 AM
You may have to add the retry logic to your custom code - the Tasklet you have implemented or the client that calls the JobLauncher. N.B. it may be possible to do this declaratively using the RetryOperationsInterceptor. If this is not convenient please explain why, otherwise I'll close this issue.
We can put the retry logic in the tasklet only at places where we are expecting some failure but the case like above can happen anywhere in the flow of the job execution so would better be handled at the framework level.
We can also put logic in the client that calls the JobLauncher but that launcher is using threadpool executor and in that case we do not get the control back to the client. We are having problem when the jobs abort because the connection to database is broken temporarily and status of the jobs remains as STARTING or STARTED because the spring batch also would not be able to update the database with the FAILED status. In that case, retry at job should fix the issue. Until the retry is there at the job level, we are planning to create a cleaner job which runs every minute, checks the status of each jobs and if the job status is STARTED or STARTING but the job has aborted then restarts the job. But we do not know how to find out whether the job has really aborted or is still running. Can you guide us how we can achieve that? Thanks, Rajiv It would be much easier to use RetryTemplate or RetryAdvice (the name was changed) to wrap you calls to the step, job or launcher. I would not recommend implementing any of those interfaces yourself, so if you want to use RetryTemplate then it has to go in the client that calls the launcher. For the AOP approach it is non-invasive in all cases and should not require you to implement any framework interfaces. You are correct that this is a framework concern, and that is one reason why we provide those tools.
Given the StatefulRetryStepFactoryBean added in rc1, and Dave's comments about the interceptor, it looks like this issue can be closed?
Step-level retry can be implemented using a StepExecutionListener that throws an exception (to trigger the retry - in 2.0 steps never throw exceptions in normal circumstances), and a RetryOperationsInterceptor around Step.execute() (targeted with bean= or an old style ProxyFactoryBean), or with a Tasklet / retry combo. We could still look at this in a later release so I'll leave it open. At the job level retry would be a scheduling concern, and not really in scope for Spring Batch. Might be addressed in the enterprise offering.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Need RetryPolicy at Step and Job Level
