Retry after all S3 get failures that made progress #88015
Merged
Conversation
This file contains 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
S3 sometimes enters a state where blob downloads repeatedly fail but with nontrivial progress between failures. Often each attempt yields 10s or 100s of MBs of data. Today we abort a download after three (by default) such failures, but this may not be enough to completely retrieve a large blob during one of these flaky patches. With this commit we start to avoid counting download attempts that retrieved at least 1% of the configured `buffer_size` (typically 1MB) towards the maximum number of retries. Closes elastic#87243
DaveCTurner
added
>enhancement
:Distributed Coordination/Snapshot/Restore
elasticmachine
added
the
Team:Distributed (Obsolete)
|
Pinging @elastic/es-distributed (Team:Distributed) |
|
Hi @DaveCTurner, I've created a changelog YAML for you. |
kingherc
approved these changes
Jun 24, 2022
...les/repository-s3/src/main/java/org/elasticsearch/repositories/s3/S3RetryingInputStream.java
Outdated
Show resolved
Hide resolved
| private int failuresWithoutProgress; | ||
|
|
||
| @Override | ||
| public void handle(HttpExchange exchange) throws IOException { |
There was a problem hiding this comment.
So here basically you first exhaust the "meaningless" failures, and then have a series of failures with meaningful progress that should not finally throw an exception and the blob should be successfully read (either in its entirety or partly).
There was a problem hiding this comment.
Yep, pretty much, although note that sendIncompleteContent will sometimes send a meaningful amount of data too.
|
@elasticmachine please run elasticsearch-ci/bwc - failure tracked at #87959 |
DaveCTurner
added
the
auto-merge-without-approval
DaveCTurner
deleted the
2022-06-24-S3RetryingInputStream-retry-on-progress
branch
DaveCTurner
added a commit
to DaveCTurner/elasticsearch
that referenced
this pull request
Jul 26, 2022
In elastic#88015 we made it so that downloads from S3 would sometimes retry more than the configured limit, if each attempt seemed to be making meaningful progress. This causes the failure of some assertions that the number of retries was exactly as expected. This commit weakens those assertions for S3 repositories. Closes elastic#88784 Closes elastic#88666
elasticsearchmachine
pushed a commit
that referenced
this pull request
Jul 26, 2022
In #88015 we made it so that downloads from S3 would sometimes retry more than the configured limit, if each attempt seemed to be making meaningful progress. This causes the failure of some assertions that the number of retries was exactly as expected. This commit weakens those assertions for S3 repositories. Closes #88784 Closes #88666
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.
S3 sometimes enters a state where blob downloads repeatedly fail but
with nontrivial progress between failures. Often each attempt yields 10s
or 100s of MBs of data. Today we abort a download after three (by
default) such failures, but this may not be enough to completely
retrieve a large blob during one of these flaky patches.
With this commit we start to avoid counting download attempts that
retrieved at least 1% of the configured
buffer_size(typically 1MB)towards the maximum number of retries.
Closes #87243