Skip to content

Allow configuration of status codes that cause Ribbon retries.#492

Merged
codefromthecrypt merged 6 commits intoOpenFeign:masterfrom
transferwise:retry-status-codes
May 6, 2017
Merged

Allow configuration of status codes that cause Ribbon retries.#492
codefromthecrypt merged 6 commits intoOpenFeign:masterfrom
transferwise:retry-status-codes

Conversation

@JonathanO
Copy link
Copy Markdown
Contributor

This reintroduces a behaviour present in the original Ribbon RestClient which allowed a 503 status code to be treated as a connection failure by Ribbon's retry mechanisms. Further, it makes it configurable, allowing you to specify which status codes are considered to be server throttled.

By default it preserves the current Feign ribbon-client behaviour.

I've added this feature since in our environment there's often a gateway in front of an application server which will return 502 or 503 if the application server instance is unavailable. These should be treated as retryable (but only on another server) as per the original RestClient behaviour.

Copy link
Copy Markdown
Contributor

@codefromthecrypt codefromthecrypt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some nits but otherwise looks good codewise.

@ryanjbaxter do you agree with the behavior change?

if (statusCodesString == null || statusCodesString.isEmpty()) {
return Collections.emptySet();
}
Set<Integer> codes = new HashSet<Integer>();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit always linkedhashset (prevents distraction in tests etc)

return new LBClient(lb, clientConfig);
}

private Set<Integer> parseStatusCodes(String statusCodesString) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

static? also package protected makes this testable

/**
* Uses {@link ClientFactory} static factories from ribbon to create an LBClient.
*/
public static final class Default implements LBClientFactory {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a noop as defaults to public static as member type of an interface?

}
}

IClientConfigKey<String> ServerThrottledStatusCodes = new CommonClientConfigKey<String>("ServerThrottledStatusCodes") {};
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

strange casing for constant..

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, though consistent with the similar statics in CommonClientConfigKey itself, so I thought their might be some weird convention about CommonClientConfigKey instances. If not, I'll change it to something more conventional.

@ryanjbaxter
Copy link
Copy Markdown

Yes I do. I was actually looking at an issue yesterday in Spring Cloud Netflix that was similar, in Cloud Foundry the router will return a 404 when an instance is unavailable. Typically this is not considered an error by the HTTP client so no exception is thrown and no retry happens. Maybe it is best it make it generic and have something like retryableStatusCodes and not just throttled status codes?

@codefromthecrypt
Copy link
Copy Markdown
Contributor

anything on @ryanjbaxter's last comment? in favor or against switching ServerThrottledStatusCodes to retryable ones?

@ryanjbaxter
Copy link
Copy Markdown

FYI here is the change we make in Spring Cloud Netflix. spring-cloud/spring-cloud-netflix#1836

@codefromthecrypt
Copy link
Copy Markdown
Contributor

note: release in a couple days, so here's a chance!

@JonathanO
Copy link
Copy Markdown
Contributor Author

Hi, I've done the rename.

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

Successfully merging this pull request may close these issues.

4 participants