Dave Syer
Dave Syer
It's in 1.3 I think. It looks like maybe we need an alias?
My understanding is that on shutdown the listener threads should be interrupted, and that would be picked up by the backoff policy at the end of the current backoff. So...
How about creating a simple sample project? It's probably something simple, but hard to diagnose without running actual code. There's nothing to stop you doing compile time weaving (or load...
I don’t remember ever doing it myself, but spring-retry is old enough that I expect I might have. How about that sample project?
I guess at least you need an `AnnotationAwareRetryOperationsInterceptor`? Someone else was asking about this in #191.
You can ask the `RetryPolicy` if it `canRetry(retryContext)`. That might not be super convenient, but it would tell you what you need to know, I think?
I guess we could add the `RetryPolicy` to the `RetryContext`. But why can't you use the `onClose()` callback (OP said it "was not useful" but didn't say why)?
Correct, I think (at least for stateless retry). So you need both callbacks (`onError()` and `close()`). The only problem is that you don't know for sure if there will actually...
The last exception is always available from the `RetryContext` (via `RetrySynchronizationManager`).
A stateless retry always throw the last exception (if it is an `Exception`) I think. Isn't that kind of what you want if you are setting that flag anyway?