search

Comcast / jrugged

A Java libary of robustness design patterns
Apache License 2.0
266 stars 93 forks source link

Extensions to spring-batch's RetryTemplate for retrying Callable as well as classifying exceptions as retryable based on a predicate, rather than instance type. #19

Closed mattinger closed 10 years ago

mattinger commented 11 years ago

In particular, this adds the following capability:

  1. Support for the Callable class within the ExtendedRetryTemplate
  2. A Classifier instance which is based on guava predicates
  3. Some useful predicates
  4. A retry policy which is based on a generic exception classifier, rather than the existing SimpleRetryPolicy which assumes a Map based approach to determining exception classification.
joercampbell commented 10 years ago

So - Looking over this patch - I see two things, 1) You included Spring Batch, but I don't think I see any use of that new dep. in the code you have in the patch. 2) At least on of the files in the patch has a * import. Can you point out what the addition of spring batch dependance? Did I just miss where that is being used?

mattinger commented 10 years ago

It's actually extending the spring batch's "RetryTemplate" class.

public class ExtendedRetryTemplate extends RetryTemplate

The purpose of this patch is to extend their RetryTemplate to support Runnable and Callable (which they don't support currently, and you have to implement their "RetryCallback" interface).

The built in RetryPolicy that comes with spring batch only allows an exact class match to be used for determining which exceptions trigger a retry and which don't. I have built another implementation which is based on spring's "Classifier" interface, and an implementation of "Classifier" which is based on a Predicate function. This allows the caller to make a much more dynamic decision on whether to retry. For example, they could look at the error message, sql state codes, or anything else related to the exception which was thrown.

And finally, i added some useful predicates for that, such as checking whether the given exception contains a particular string in it's message (something we kind of have to do cep, which i don't like, but it's really the only good way due to the merlin api design). I'm willing to forgo the ExtendedPredicates class if you don't find it useful for jrugged. As well as the PredicateBinaryExceptionClassifier, which is mostly a convenience for using google's Predicate interface.