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

Add ADAPTIVE_V2 retry mode to support the legacy behavior #5123

Merged

Conversation

sugmanue
Copy link
Contributor

@sugmanue sugmanue commented Apr 19, 2024

Motivation and Context

This change is aimed to prevent breaking existing users of the legacy adaptive mode while introducing the means needed for new users to onboard and use the correct adaptive implementation.

Modifications

This change introduces a new RetryMode constant, ADAPTIVE_V2 and uses the legacy ADAPTIVE retry policy by adapting it to a retry strategy using the existing adapter when the ADAPTIVE mode is requested, either by using AwsRetryStrategy.forRetryMode(RetryMode.ADAPTIVE) call, or by setting the retry_mode=adaptive value in the profile file or by using the aws.retryMode=ADAPTIVE system setting.

Customers that need or want the correct adaptive mode will need to use instead RetryMode.ADAPTIVE_V2. This will reduce the risk of breaking customers that are using the legacy mode.

Testing

Added unit tests to validate that all the current ways of configuring the retry logic in the SDK will create the expected and correct instance that implements the desired logic.

Screenshots (if appropriate)

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 changed the title Add a new ADAPTIVE2 mode to support the legacy behavior Add ADAPTIVE_V2 retry mode to support the legacy behavior Apr 25, 2024
Copy link

sonarcloud bot commented Apr 25, 2024

@aws aws deleted a comment from Crissttianreyes Apr 25, 2024
@sugmanue sugmanue marked this pull request as ready for review April 26, 2024 00:20
@sugmanue sugmanue requested a review from a team as a code owner April 26, 2024 00:20
@sugmanue sugmanue requested a review from dagnir April 26, 2024 18:31
Comment on lines 88 to 89
* from remembering its state across requests which is needed to correctly estimate its sending rate. Given that the
* this bug has been present since its introduction and that correct version might change the traffic patterns of the SDK we
Copy link
Contributor

Choose a reason for hiding this comment

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

"Given that the"

* @deprecated As of 2.25.xx, replaced by {@link #ADAPTIVE_V2}. The ADAPTIVE implementation has a bug that prevents it
* from remembering its state across requests which is needed to correctly estimate its sending rate. Given that the
* this bug has been present since its introduction and that correct version might change the traffic patterns of the SDK we
* deemed too risky to fix this implementation..
Copy link
Contributor

Choose a reason for hiding this comment

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

repeated period

Comment on lines 101 to 105
* Adaptive V2 mode differs from {@link #ADAPTIVE} mode in the computed delays between calls, including the fist attempt
* that might be delayed if the algorithm considers that it's needed to increase the odds of a successful response. The
* previous Adaptive mode is also designed to work like so but a bug present since its introduction prevents it from
* preserving its internal state across requests.
* <p>
Copy link
Contributor

Choose a reason for hiding this comment

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

s/fist/first/

Also should "Adaptive" be capitalized?

The
     * previous Adaptive mode is also designed to work like so but a bug present since its introduction prevents it from
     * preserving its internal state across requests.

I don't think it's necessary to specify that ADAPTIVE is also supposed to work this. If we link back to ADAPTIVE from here I think that's sufficient

Comment on lines 116 to 119
if (retryMode == RetryMode.ADAPTIVE_V2) {
throw new UnsupportedOperationException("ADAPTIVE_V2 is not supported by retry policies, use a RetryStrategy "
+ "instead");
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we move this check to Builder instead?

Copy link
Contributor Author

@sugmanue sugmanue May 1, 2024

Choose a reason for hiding this comment

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

I moved this to the builder, not sure what's the reason behind it but I guess it's the same.

@sugmanue sugmanue merged commit 67b7844 into feature/master/sra-retries May 1, 2024
14 of 16 checks passed
@sugmanue sugmanue deleted the sugmanue/sra-retries-fix-adaptive-mode branch May 1, 2024 20:34
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.

None yet

2 participants