This is purely a marker interface, but might be useful for other tools looking to apply retry advice (they should usually not bother if the bean already implements Retryable)
So RetryCallback<T, E extends Throwable> and the E parameter appears in RetryOperations too, making it possible to call it with an unchecked exception type in the parameter and not catch exceptions. Users should beware: it's just syntactic sugar, and the actual runtime type of the exception is never checked at runtime. So, for instance, declaring a RetryCallback<Object,IllegalArgumentException> doesn't mean that other Exceptions won't be retried, just that you won't be able to explicitly throw them if they are checked. A project using Spring Batch 2.2 was used to test that this works with user code that uses a library compiled agains Spring Retry 1.0. Fixes gh-6
This allows use of spring-retry with naughty libraries that use Error conditions to signal retryable exceptions. Users can still declare their RetryCallback as "throws Exception" if they want to be conservative. Also added throwLastExceptionOnExhausted to RetryTemplate to throw the last exception instead of the ExhaustedRetryException.
Add ASL 2.0 license text
Consider Foo caused by Bar caused by Baz. If Bar is categorized TRUE and Baz categorized FALSE, classiy() should return TRUE (hit on Bar), but it returned FALSE. The early exit from the cause traversal was not taken because we were always testing against the top level throwable (Bar). Add a test to verify this scenario; test against the cause on each iteration through the loop.
With Spring AMQP, the exception thrown to the RetryTemplate is a ListenerExecutionFailedException with the business exception in the cause. This means Exception categorization does not work. Provide a retry policy/classifier that can examine exception causes until a match is found. If so configured, the retry policy should categorize exceptions by traversing the cause if the current exception is not itself categorized.
The old version was still very prone to multiple threads marching in lock step. It is better to use random backoffs (with some exponential growth).
# By Michael Minella * mminella-BATCH-1718: BATCH-1718: Added optimistic flag
- Gives better performance when run in a very contentious environment. Specifically when running multi-threaded tests where all threads may start at the same time.
- The RetrySimulator can be used to calibrate retry + backoff tuples.
* AMQP-226: AMQP-226 Fix Exponential Back Off
Previously, for stateful environments,the multiplier had no effect and the backoff policy always slept for the initial interval. AMQP-226 Polishing Using AttributeAccessor interface instead of concrete RetryContextSupport.