Conversation
Co-authored-by: Nicola Dardanis <ndardanis@adobe.com>
9 tasks
francoisledroff
commented
Feb 1, 2024
| .logLevel(Level.NONE) | ||
| //.logLevel(Level.FULL) // use this instead when debugging | ||
| .decode404() | ||
| .retryer(new Retryer.Default(1000, SECONDS.toMillis(4), 3)) |
Collaborator
Author
There was a problem hiding this comment.
don't you think we should allow the users to specify the retries through conf here ?
same as for the log level see #146
nicdard
approved these changes
Feb 12, 2024
9 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Configure Retries in Feign utility:
Related Issue
#150
#151
Motivation and Context
This would better tune calls retries. We do not want in general to retry too much, and we want more time between each of the calls to wait for the called system to recover. Note that even in case of a retry after header present in the response, the maximum waiting period will be used in place of the time specified in the response to place the next call when lower:
which is ok to protect the service for hanging up for too long. 4s seems like a reasonable time to wait before retrying and eventually fail, also, the maximal waiting period that can be calculated with the given parameters by the exponential backoff strategy fits the maximum as well.
Another solution would be the approach proposed here: #149
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: