[aws-cpp-sdk-s3-crt]: TransferManager for S3CrtClient #2380
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.
This is a self-contained implementation of the
TransferManager
for s3-crt, taken from working production code.It solves the problem of handling bulk transfers in parallel.
The API looks mostly similar (hence keeping the copyright note), but there are several differences.
Main differences
The existing
TransferManager
uses thread pools and thread management, which are not required for s3-crt.1. Catch local write errors
In order to avoid corruption (e.g. due to a full filesystem), it was important for us to also monitor local write errors, and declare a transfer as failed when file data could not be written out.
This is implemented via an error callback which affects the state of the transfer. It also necessitates an intermediate
FAILING
state, to properly handle state transition when the final.shutdown_callback
is called.2. Atomic file creation
It was important for us that files are created in a transaction-like fashion: a destination file should only exist if the transfer and the local writes succeed.
To accomplish this, data is written to a "partial" file with a suffix (
<fileName>.partial-xxx
), and renamed into<fileName>
on successful completion. On failure, the "partial" file is removed by the destructor.3. Cancel-on-first-failure policy
This is similar to (2). Bulk-transfer files are often related so that users are likely not interested to obtain a subset if one or more transfers fail.
Implemented by adding an optional "cancel on first failure" policy.
4. Support for S3 storage tags and object metadata
Implemented by adding these to the corresponding requests.
Not covered by this PR
TransferManager
usess3://<Bucket>/<Key>
. This could be changed easily.AWS Checklist
Check all that applies:
Check which platforms you have built SDK on to verify the correctness of this PR.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.