-
Notifications
You must be signed in to change notification settings - Fork 863
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
Transfer Manager #37
Comments
Upload and download return a Transfer which has getProgress(). This returns a simple way to get a percent complete but requires you to do busy loops to update things like UIs. On the other hand, ProgressListener only returns the bytes transferred causing you to have to do the percentage manually and not very easy since the total size is not exposed. Better feature parity on the ProgressListener would be nice since that plays better with async |
+1 on parity with progress listener. There should probably just be one system between transfer manager and the rest of the SDK for monitoring progress. |
Use DirectoryStream for loading files from a directory to avoid having to load all file names into memory. See aws/aws-sdk-java#1271. |
Unreasonable to expect the thread-pool will be unbounded in order to avoid deadlocks see : aws/aws-sdk-java#939 |
TransferManager features requests from v1: aws/aws-sdk-java#117 |
Allow using a finite number of threads for background processing. Currently, 1.11.x's |
+1 for aws/aws-sdk-java#1103, a request for the ability to limit bandwidth for S3 uploads/downloads. See also the recently closed issue from the aws-cli repo: This same feature would be similarly useful in the Java SDK to help avoid fees from ISPs for excessive bandwidth usage, or to prevent a single application from overwhelming a network's capacity. |
+1 for aws/aws-sdk-java#1103, too fast data downloading will saturate the network usage. |
+1 for aws/aws-sdk-java#474. It is very inefficient to write to the file system then upload from the file when I have an object in memory I can serialize directly to a stream. It seems counterintuitive to provide the total content length up front when providing a stream as input - I have to work around it instead of just use it. |
+1 for aws/aws-sdk-java#893 The primitive AmazonS3 client is capable of uploading and downloading to and from a stream, as well as from a file. The TransferManager can also upload from either a stream or a file, but can only download to a file - not a stream. Symmetry in the interface would be nice. For large files - the kind for which multi-part uploads are most valuable - I can understand that attempting to buffer contents in memory is unwise. However, for small files, I question the value of having to write and read from disk. The download/upload interface is pleasingly abstract, relative to the interface of the primitive client, and I'd like to favor it no matter the size of my files. |
+1 for aws/aws-sdk-java#1207. I need to be able to upload a lot of files all at once while specifying the ACL. Our customers will be using the CLI to upload files in parallel and I need to closely match the performance in simulating file uploads. If I don't specify the ACL flag, our service cannot read those files and my tests are useless. |
+1 for aws/aws-sdk-java#893 My current use-case for this is that I have 100MB+ compressed (GZIP) files on S3 that I need to download and perform some further conversion on. It would be great to take advantage of multi-part download and have that stream through Java's GZIPInputStream so that I don't need to download and then uncompress separately. |
Is is possible to support the aws cli style of "sync" where TransferManager decides which files are different and only uploads the different ones? |
Reminder that for aws/aws-sdk-java#474, I have written a library using the SDK v1 which allows streaming data to S3 without knowing the size beforehand and without keeping it all in memory or writing to disk. You may find the source code helpful for implementing the feature in v2. I am not planning on porting the library to use v2. Implementing the feature in v2 may have advantages over my library, e.g. by using asnyc non-blocking I/O instead of many threads. @sql4bucks see the library if you haven't already, you may find it useful. |
Thanks @alexmojaki. We will keep this in mind when investigating how to address aws/aws-sdk-java#474. |
Hi all, For anyone interested, here is the current design for TransferManager: https://github.com/aws/aws-sdk-java-v2/tree/master/docs/design/services/s3/transfermanager. Feel free to leave feedback and comments! The README will be updated soon to go into depth on current prototype. |
When can this be expected for use? And which version? |
This adds initial support for S3TransferManager TransferListeners. The motivation and design is consistent as outlined in aws#2729. It also addresses some customer asks as mentioned in aws#37. Every @SdkPublicApi has been thoroughly documented with its description and usage instructions where applicable.
Add support for S3TransferManager TransferListeners This adds initial support for S3TransferManager TransferListeners. The motivation and design is consistent as outlined in #2729. It also addresses some customer asks as mentioned in #37. For more context, see the discussion in #2770. Every @SdkPublicApi has been thoroughly documented with its description and usage instructions where applicable.
downloadDirectory is missing. |
When using the TransferManager API (see https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/transfer-manager.html), I'm experiencing an exception like? Is there any way to ensure the underlying S3Client is okay when using the TransferManager? How can you validate that it is properly configured? Setting it up is straightforward: but there's no way, that I'm aware of, to see if things are properly configured. It might be nice to be able to expose the underlying (or specify) the HTTP Client for this sort of validation testing. |
Do you have a target in mind for moving to a non-preview release? |
We do have a target in mind, but unfortunately we can't share dates. We're making steady progress, though, and there's not many features left in the backlog before GA! Sorry, I know that dates would be really helpful for planning purposes. |
Can you confirm if #474 (highest upvoted above) will get prioritized? (and if not - why?) |
Hi all, to provide an update, below are the features that will be included in the GA release. The only remaining feature that we are currently working on is
We will use separate issues to track features that are not in GA scope (they will get prioritized based on the number of 👍🏼s). |
@djchapm as mentioned in #2714 (comment), this feature is in our backlog, and we will track it in #139 |
@zoewangg what about aborting the upload? Is there a plan to add a method for that in TransferManager v2 (as it was in v1)? |
@kingan379 you can cancel the transfer by cancelling the future in the returned upload, |
Is there a plan to support InputStream in S3TransferManager? |
Hello! |
|
Hi @AlexOkayJ, client encryption support is tracked in #34 |
Hi @kingan379, it's supported now. You can use
|
I commented this s3ClientConfiguration, but now, the join() method is throwing this error:
Exception in thread "main" java.util.concurrent.CompletionException: software.amazon.awssdk.core.exception.SdkClientException: Unable to execute HTTP request: SSLEngine closed already |
Review the inherited state of the V1 transfer manager and determine which changes are necessary for V2.
(Feel free to comment on this issue with desired changes).
The text was updated successfully, but these errors were encountered: