* Deprecate `ObjectWaitSleeper` and replace it with `ThreadWaitSleeper`
* Improve `SimpleMethodInvoker`
* Use `if (logger.isDebugEnabled())` for better performance
The `RetryTemplate` continues to invoke `canRetry(retryPolicy, context)` with retry loop, because some end application may rely on that logic.
Although it looks like overhead to call `canRetry()` twice a retry: it might be heavy operation, e.g. check the state of external system
Fixes gh-10
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.
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.
- 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.
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.
