-
Notifications
You must be signed in to change notification settings - Fork 26
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
Starting a multi-input-stream large file upload, and adding the input streams later one-by-one. #96
Comments
Hi Bruce -- Great question. As you point out, there's definitely an API for uploading parts and we definitely have code in the SDK that does that. It could be exposed. Before we dive into that, we should talk more about your use case to make sure that whatever we decide upon will actually help you. Because the SDK may need to retry uploads, our ContentSource objects must be able to create an InputSource on demand that starts at the beginning of your content. When you say you already have an input stream, are you able to create it on demand or is someone posting it to you outside your control? thanks, |
Thanks for the prompt response! The part input stream source is mostly out of my control, coming from a different library which allows for generic implementation of cloud storages, but it assumes we manage the parts and retry functionality. I appreciate the ease of use which the wrapper allows, but I'd also like to be able to access the low level implementation, maybe as a "not recommended, but here you go anyway - use this like you would the REST API" type of thing. Many thanks! |
Hi Bruce --
Ok. You said the magic words -- you're willing to sign up for doing the
retry logic. :)
Take a look at B2StorageClientWebifierImpl. It's the class responsible for
turning an abstract desire to upload a part to the call to the WebApiClient
call that does the work. I'm not sure how you are creating your
B2StorageClient, but you definitely have a webifier, even if it's the
default one built by some higher-level code.
Webifier methods are usually called from inside an invocation of
retryer.doRetry(). See B2LargeFileUploader.uploadOnePart() to see how the
SDK is calling the webifier's uploadPart. A lot of the code in there is
related to setting up progress notifications and making a substream from
the large file. Do notice that we're using an B2UploadPartUrlCache to
reuse upload urls and authorizations.
I'm not sure if B2Retryer and/or B2DefaultRetryPolicy will be useful for
you, but you might want to look at them to understand the different cases
we handle today. In particular, some errors need to be retried and some
are unretryable.
I'd be happy to review your approach with you before you get too far and
happy to look at any PR.
thanks,
ab
…On Wed, Dec 4, 2019 at 5:44 PM Bruce Emehiser ***@***.***> wrote:
Thanks for the prompt response!
The part input stream source is mostly out of my control, coming from a
different library which allows for generic implementation of cloud
storages, but it assumes we manage the parts and retry functionality.
I appreciate the ease of use which the wrapper allows, but I'd also like
to be able to access the low level implementation, maybe as a "not
recommended, but here you go anyway - use this like you would the REST API"
type of thing.
I'd be fine implementing retry myself.
Many thanks!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#96?email_source=notifications&email_token=ABHJFCXTXZF64YWZSDALSX3QW7T6JA5CNFSM4JVLAAAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF54USQ#issuecomment-561760842>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABHJFCQVRMTPQSL3YWJZUNDQW7T6JANCNFSM4JVLAAAA>
.
|
@certainmagic, I got the functionality I wanted to work by
I can mark the input stream for a given part, and reset it if the B2ContentSource requests a new input stream, so letting the client manage the retry for any given part is fine. I'm sure it's not the prettiest way, but it seems to work fine for my use case, and it would be nice functionality to have in the SDK (assuming it doesn't exist already, and I've managed to miss it.) |
Thanks, Bruce. I need to involve the developer who worked on the large
file stuff most recently. We'll take a look.
ttfn,
ab
…On Tue, Dec 10, 2019 at 1:46 PM Bruce Emehiser ***@***.***> wrote:
@certainmagic <https://github.com/certainmagic>, I got the functionality
I wanted to work by adding a method to the B2StorageClient which allows me
to upload a single part.
I'm sure it's not the prettiest way, but it seems to work fine for my use
case, and it would be nice functionality to have in the SDK (assuming it
doesn't exist already, and I've managed to miss it.)
***@***.***
<bemehiser@22be8f6>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#96?email_source=notifications&email_token=ABHJFCWUTLUUBIAVOAEETLDQX6MSHA5CNFSM4JVLAAAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGPIZZI#issuecomment-564038885>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABHJFCRL7D7DF2IKXUYPNPLQX6MSHANCNFSM4JVLAAAA>
.
|
Hi Bruce -- Thanks for making that version. I'd like to be able to figure out the right way to add this Now that you have your version, are you unblocked? Or are thanks, |
I'm unblocked. Many thanks. |
hi -- btw, i haven't forgotten about this. i took a few stabs at making a clean version in mid-December, but haven't gotten anything good yet. it could be a while before i get back to it. ttfn, |
I'm trying to
I get the parts as input streams, and one would assume from the REST API that I should be able to upload them one by one. However, it looks like I either need to have all input streams when I start the upload, or copy the data from each input stream to another input stream which the upload is using, and let it manage the parts.
Is it possible to use generic part upload functionality like the REST API b2_upload_part with each input stream as I acquire it, or can that functionality be added or exposed?
I'm currently using revision 3dfc97 (2019-10-08)
The text was updated successfully, but these errors were encountered: