Open xdhmoore opened 9 years ago
I believe I found a solution: creating my own Throwable->Boolean classifiers that I can wrap with a Throwable->RetryPolicy classifier in the ExceptionClassifierRetryPolicy. Then before I kick off my async code, I can call the appropriate Throwable->Boolean classifier to determine if retry is wanted without having to initialize a RetryContext.
Here is my scenario:
I want my first operation to be synchronous & upon failures, my subsequent operations (retries) to be asynchronous. To do this, I put the first attempt outside of spring retry and then wrapped the rest in a RetryTemplate nested inside an asynchronous hystrix command. This is probably not an ideal use of hystrix, but it is working fine. However, now I am trying to implement an ExceptionClassifier, and I am having trouble determining the best way to skip my asynchronous code based on how the first exception is classified, because I'm not sure how to get ExceptionClassifierRetryPolicy.canRetry() to return false on the 1st call. Also, in my scenario, I don't really want to just create a new async thread just to drop it.
It looks like I may have to call my classifier directly, get back a RetryPolicy and try to initialize it so that I can call canRetry directly before I hit async-land so I can know whether to skip retry. Then if not skipping I guess I would try and clear the context (maybe?) afterwards, so it doesn't screw up the normal RetryTemplate process. Would love to know if there is a better way. I think all of this would be solved if there was a way to do a synchronous first attempt and then asynchronously retry.
On another note, thanks for the project!. It is neat and I've enjoyed trying to figure out how the code works. Learned about volatile, soft references, and ThreadLocal today. :)
If this wasn't coherently stated enough, let me know and I'll clarify. I'm a little brain-damaged at the moment.