-
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
Investigate removing retries from s3 blob store #22845
Labels
:Distributed Coordination/Snapshot/Restore
Anything directly related to the `_snapshot/*` APIs
help wanted
adoptme
Comments
+1
Correct |
I agree. I'd just like to double-check with @tlrx as he introduced this feature with elastic/elasticsearch-cloud-aws@cbe82d2 |
+1 too, I think we can remove the discuss label. |
abeyad
pushed a commit
to abeyad/elasticsearch
that referenced
this issue
Apr 6, 2017
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
abeyad
pushed a commit
that referenced
this issue
Apr 6, 2017
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
abeyad
pushed a commit
that referenced
this issue
Apr 7, 2017
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
:Distributed Coordination/Snapshot/Restore
Anything directly related to the `_snapshot/*` APIs
help wanted
adoptme
The s3 client has a maxRetries setting, which is uses internally for retrying throttled requests. The setting is also read by the s3 blob store, and a while{try/catch} is used along with retries (but without backoff). It appears this outer retry mechanism may have existed for throttling before the sdk client did that, or also for eventual consistency. For the latter, this should no longer be a problem, as currently s3 provides read-after-write consistency for new PUTs (and afaik we should not be overwriting blobs). This issue is to discuss removing the retries from the blob store (but not the client).
The text was updated successfully, but these errors were encountered: