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

Catch RemoteFileChangedException inside of S3DynamoDBLogStore::read #1712

Conversation

scottsand-db
Copy link
Collaborator

@scottsand-db scottsand-db commented Apr 21, 2023

Description

In S3, if N.json is over-written while an input stream is open on it, then the ETag will change and a RemoteFileChangedException will be thrown.

This PR adds logic to retry reading that N.json file, at the exact same line that the error occurred at.

This assumes and requires that the contents of N.json have been overwritten with the same identical content!

As an important implementation highlight: so, if we are at index 25 (thus, the last successfully read index is 24), and we try to call .next() on the read iterator, and an RemoteFileChangedException is thrown, we will re-generate the read iterator, skip all the way to index 25, and try reading it again.

How was this patch tested?

New UTs.

Does this PR introduce any user-facing changes?

No.

@scottsand-db scottsand-db self-assigned this Apr 21, 2023
@tdas
Copy link
Contributor

tdas commented Apr 24, 2023

Specify in the description that the content of the overwritten file is expected to be exactly same. Without that this entire thing does not make sense at all.

Copy link
Member

@zsxwing zsxwing left a comment

Choose a reason for hiding this comment

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

Mostly style comments.

One improvement we may consider in the future is that we can calculate the md5 for the file content we have seen. When replaying the iterator, we can calculate the md5 for the new content and compare it with the existing value we have. This would allow us to detect really data loss issues. Of cause, this can only detect unexpected file overwriting when reading a json file. If the unexpected file overwriting happens when we are not reading the file, there is nothing we can do.

Copy link
Member

@zsxwing zsxwing left a comment

Choose a reason for hiding this comment

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

RetryableCloseableIterator.java looks good to me.

Left only one comment about the FileAlreadyExistsException issue. You can fix it in this PR and update the PR description, or revert changes for FileAlreadyExistsException and fix it in a separate PR.

@@ -351,7 +359,12 @@ private void fixDeltaLog(FileSystem fs, ExternalCommitEntry entry) throws IOExce
fixDeltaLogPutCompleteDbEntry(entry);
LOG.info("fixed {}", entry.fileName);
return;
} catch(Throwable e) {
} catch (java.nio.file.FileAlreadyExistsException e) {
Copy link
Member

Choose a reason for hiding this comment

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

writeCopyTempFile calls copyFile, which has the same issue (a concurrent reader or writer copies the file before writeCopyTempFile is finished). Should we just change copyFile instead?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

hm, so what would that change be?

  1. copyFile does not throw FIleAlreadyExistsException? i.e. the assumption is that we will only ever copy T(N) -> N.json, (i.e. no other content will be written to N.json .... so if we do duplicate copies then that's fine, don't throw)

  2. copyFile copies with overwrite=true?

Copy link
Member

Choose a reason for hiding this comment

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

copyFile does not throw FIleAlreadyExistsException?

This one

copyFile copies with overwrite=true?

Not this one because we want to avoid overwrite if possible

Copy link
Member

@zsxwing zsxwing left a comment

Choose a reason for hiding this comment

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

LGTM

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.

4 participants