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

Can't chose correct @Recover method #188

Open
xytrams opened this issue Nov 12, 2019 · 4 comments
Open

Can't chose correct @Recover method #188

xytrams opened this issue Nov 12, 2019 · 4 comments

Comments

@xytrams
Copy link

xytrams commented Nov 12, 2019

In case of multiple @Recover method, apparently only one is considered, others are ignored.
Example:

@CircuitBreaker(openTimeout=1000, resetTimeout=2000, maxAttempts=2)
public Response submit(Object o) {
... retry logic with retryTemplate
}
@CircuitBreaker(openTimeout=1000, resetTimeout=2000, maxAttempts=2)
public Response query(String id) {
... retry logic with retryTemplate
}
@Recover
public Response fallbackForSubmit(Throwable e, Object o) {....}
@Recover 
public Response fallbackForQuery(Throwable e, String id) (....}

In my case fallbackForQuery is not considered as recovery method.
If I comment out fallbackForSubmit recover method - than it works.

I've seen there were some changes introduced to allow to add @Retry(recoverName="recover1") in #85 , but it is not exactly my scenario since I'm not using @Retry annotation but rather retryTemplate.

Could you advise how should I proceed with my problem?

@dsyer
Copy link
Member

dsyer commented Jan 20, 2020

Did you try @Retryable(recover=...) (note the spelling of both annotation name and attribute)? Or is it just that you need the @CircuitBreaker to alias that attribute before it will work? Your comment about "using retryTemplate" didn't make sense to me.

@Nocturne183
Copy link

@dsyer when will this recover parameter be available in Branch 1.2.X ?

currently I'm working with 1.2.5.RELEASE which doesn't contain this yet.

@dsyer
Copy link
Member

dsyer commented Mar 9, 2020

It's in 1.3 I think. It looks like maybe we need an alias?

@xytrams
Copy link
Author

xytrams commented Jun 9, 2021

@dsyer Sorry, I completely forgot about this one. I'll try to remember from memory what was scenario (please allow some latitude - it was 2 years ago)
In one of my services I had to reach out to two external calls to different clients (urls) which could be unreliable, so decision was made to annotate both of them with @CIRCUITBREAKER. Two different @CIRCUITBREAKER weren't the problem, but eventually I needed two different @recover for each of them - and this couldn't be distinguished which @recover belongs to which @CIRCUITBREAKER. So yes, some alias or name of @CIRCUITBREAKER with corresponding alias or name of @recover should solve the problem.

Once again - apologies for late reply.

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

3 participants