-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Upload blob async frozen when using memory stream, no error #10814
Comments
I've also tried with a real azure blob storage with a sas uri:
same result, so it does not seem related to Azurite, it must be something in my code sample or with the Azure.Storage.Blobs 12.4.0 |
Just ran another test with a different stream. This time I read a PDF as a FileStream
Not sure whether the stream is not properly created and opened to be read, but in any case maybe it should throw some error and not freeze. The sample below works fine.
|
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @xgithubtriage. |
I was also having this issue. I found that I had to reset the position to 0 to get this to work.
|
I have the same problem with the DataLake Gen2 APIs. |
Seems like a bug, when the stream position is not reset the expected behavior should be uploading an empty blob, not hanging. |
@kasobol-msft can you please triage |
Not sure if it's appropriate to rewind customers stream. Does MemoryStream.Read hang when it's at the end? AFAIK it returns 0 immediately https://github.com/dotnet/runtime/blob/master/src/libraries/System.Private.CoreLib/src/System/IO/MemoryStream.cs#L354 |
I'm seen MemoryStream.Read() hang when it's at the end. We can reproduce fairly easily by writing data to a memory stream, and then attempting to upload it without rewinding it. |
Just tried it,
Outputs:
|
We end up calling |
I'm not arguing that upload doesn't hang, just wonder if it hangs on memoryStream.Read or something else like our parallel upload logic. |
Try MemoryStream.Read() on a non-empty MemoryStream where offset == length. |
var bytes = new byte[100];
var s = new System.IO.MemoryStream(bytes);
for (int i = 0; i < 5 ; i++)
{
Console.WriteLine($"{s.Position} {s.Length}");
Console.WriteLine(s.Read(bytes));
}
|
Hmm maybe we are seeking outside the range of the MemoryStream or something in our Upload logic. |
Have the same issue - about an hour saved. Thank you for this! |
No. Uploading a stream starting from a arbitrary position is a totally normal practice in .net and we shouldn't artificially limit it. In addition some streams don't track their position and throw instead. I'm also worried that it would hide a real issue we have. |
I think we should do something to address this, the current user experience is non-optimal. What if we check if stream.Position == stream.Length? |
We should find why we hang instead of exiting the upload loop when |
This problem also occurs for small streams, that we attempt to upload in a single request. Is this an issue in other SDKs based on Core? |
No others that I know of. |
As I understand it, this is what happens: In
This setup the content-length of the request. This will be incorrect when Then in
This will write the stream to the request. But since the expected length is incorrect it never completes. I am sure it is more complicated than this, but this I what I found anyway :-) I have created a PR #12901 that fixes, or at least reduces this problem. |
I'm experiencing a problem with Azure.Storage.Blobs 12.4.0
No error, just frozen forever when trying to upload a stream (an in-memory json string) using Azurite.
It seems the server receives the attempt, but does nothing and the API does not throw any error either:
Azurite is running, I can access with the Azure Blob Storage Explorer and generate a sas token uri pasted below.
My code:
PS: The Azurite I use for the test is:
Can anybody spot what the issue might be?
The text was updated successfully, but these errors were encountered: