-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Removes the retry mechanism from the S3 blob store #23952
Conversation
Currently, both the Amazon S3 client provides a retry mechanism, and the S3 blob store also attempts retries for failed read/write requests. Both retry mechanisms are controlled by the `repositories.s3.max_retries` setting. However, the S3 blob store retry mechanism is unnecessary because the Amazon S3 client provided by the Amazon SDK already handles retries (with exponential backoff) based on the provided max retry configuration setting (defaults to 3) as long as the request is retryable. Hence, this commit removes the unneeded retry logic in the S3 blob store and the S3OutputStream. Closes elastic#22845
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thank you! I left one suggestion, which would be fine to do as a followup.
@@ -340,7 +340,7 @@ The default behaviour is to detect which access style to use based on the config | |||
storageClass, pathStyleAccess); | |||
|
|||
AmazonS3 client = s3Service.client(metadata.settings(), maxRetries, useThrottleRetries, pathStyleAccess); | |||
blobStore = new S3BlobStore(settings, client, bucket, serverSideEncryption, bufferSize, maxRetries, cannedACL, storageClass); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maxRetries
is now just used for logging above, which I don't think is necessary, or should not be done here. I think reading that setting can be moved down into building the client?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still LGTM. |
thanks for the review @rjernst |
Currently, both the Amazon S3 client provides a retry mechanism, and the S3 blob store also attempts retries for failed read/write requests. Both retry mechanisms are controlled by the `repositories.s3.max_retries` setting. However, the S3 blob store retry mechanism is unnecessary because the Amazon S3 client provided by the Amazon SDK already handles retries (with exponential backoff) based on the provided max retry configuration setting (defaults to 3) as long as the request is retryable. Hence, this commit removes the unneeded retry logic in the S3 blob store and the S3OutputStream. Closes #22845
Currently, both the Amazon S3 client provides a retry mechanism, and the
S3 blob store also attempts retries for failed read/write requests.
Both retry mechanisms are controlled by the
repositories.s3.max_retries
setting. However, the S3 blob store retrymechanism is unnecessary because the Amazon S3 client provided by the
Amazon SDK already handles retries (with exponential backoff) based on
the provided max retry configuration setting (defaults to 3) as long as
the request is retryable. Hence, this commit removes the unneeded retry
logic in the S3 blob store and the S3OutputStream.
Closes #22845