Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Synchronous first attempt, asynchronous retries #31

Open
xdhmoore opened this issue Jul 25, 2015 · 1 comment
Open

Synchronous first attempt, asynchronous retries #31

xdhmoore opened this issue Jul 25, 2015 · 1 comment

Comments

@xdhmoore
Copy link

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.

@xdhmoore
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant