Skip to content

Add adaptive retry strategy #3957

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

Merged

Conversation

sugmanue
Copy link
Contributor

This new module includes the interfaces and classes that will be used to implement the new retry logic within the SDK.

Motivation and Context

As part of the Smithy Reference Architecture this change adds the new default adaptive strategy.

Modifications

No modifications to existing code were made. We will make those changes in follow up pull requests.

Testing

  • Added unit tests for the new AdaptiveRetryStrategy

Screenshots (if appropriate)

N/A

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Checklist

  • I have read the CONTRIBUTING document
  • Local run of mvn install succeeds
  • My code follows the code style of this project
  • My change requires a change to the Javadoc documentation
  • I have updated the Javadoc documentation accordingly
  • I have added tests to cover my changes
  • All new and existing tests passed
  • I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
  • My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

  • I confirm that this pull request can be released under the Apache 2 license

@sugmanue sugmanue requested a review from a team as a code owner April 27, 2023 21:53
@sugmanue sugmanue assigned sugmanue and joviegas and unassigned sugmanue Apr 27, 2023
/**
* Updates the estimated send rate after a successful response.
*/
public RateLimiterUpdateResponse updateRateAfterSuccess() {
Copy link
Contributor

Choose a reason for hiding this comment

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

I see that the implementation at https://github.com/aws/aws-sdk-java-v2/blob/master/core/sdk-core/src/main/java/software/amazon/awssdk/core/internal/retry/RateLimitingTokenBucket.java uses commonly accepted API naming conventions, such as refill() as direct API of the bucket

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I have seen that as well. This class encapsulates that logic and exposes a better naming which makes the reading of the code using it easier to understand.

}
}

private static class TransientState {
Copy link
Contributor

Choose a reason for hiding this comment

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

It would be really helpful for readability if we could have APIs related to tokenBucket in RateLimiterTokenBucket class and other methods in a Helper class

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure what you mean by "other methods", all the code contained in this class is related to the rate limiter token bucket. Can you please point me which methods you think should go into a different class?

Copy link
Contributor

@joviegas joviegas May 4, 2023

Choose a reason for hiding this comment

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

I was trying to suggest that we limit the responsibilities of the RateLimiterTokenBucket class to acquiring and refilling tokens, and leave other functionalities like refilling based on success, exception, or throttle exception to be handled by a separate wrapping or helper class. This way, the RateLimiterTokenBucket class can focus solely on acquiring and refilling tokens, while the helper class can handle scenarios where tokens need to be acquired or refilled based on success or failure.
That we can limit RateLimiterTokenBucket responsibility to just acquire and refill and the helper class will acquire/refill based on the success failure scenarios

Copy link
Contributor

Choose a reason for hiding this comment

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

Other methods are methods that updates the tokens based on error/success criteria like updateRateAfterThrottling etc

});
}

private <T> StateUpdate<T> updateState(Function<TransientState, T> mutator) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry for repeating the reference of RateLimitingTokenBucket but the java docs followed in that class is very helpful , can we add similar java docs here too

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, we can add something similar.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have added some doc comments when appropriate, but I did not add any of the java docs that shows the pseudo-code of the method being implemented such as:

    /**
     * <pre>
     * _CUBICThrottle(rate_to_use)
     *   calculated_rate = rate_to_use * BETA
     *   return calculated_rate
     * </pre>
     */
    // Package private for testing
    double cubicThrottle(double rateToUse) {
        double calculatedRate = rateToUse * BETA;
        return calculatedRate;
    }

Since I think those actually makes the reading harder.

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay ,It would be great if the PR included a brief description of the modifications made to the classes, specifically in terms of their relationships.

@sonarqubecloud
Copy link

sonarqubecloud bot commented May 4, 2023

SonarCloud Quality Gate failed.    Quality Gate failed

Bug C 1 Bug
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 18 Code Smells

82.6% 82.6% Coverage
5.7% 5.7% Duplication

@sugmanue sugmanue merged commit 1be6b33 into feature/master/sra-retries May 5, 2023
@sugmanue sugmanue deleted the sugmanue/add-adaptive-retry-strategy branch May 5, 2023 20:31
@sugmanue sugmanue restored the sugmanue/add-adaptive-retry-strategy branch May 5, 2023 21:09
@joviegas joviegas mentioned this pull request May 9, 2023
12 tasks
@sugmanue sugmanue deleted the sugmanue/add-adaptive-retry-strategy branch May 9, 2023 17:13
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.

2 participants