Azure Blob 存储 .NET 客户端请求超时

Question

I'm trying to understand the behavior of handling network errors in the Azure Storage .NET client. In short, my issue is:

If I pull my network cable while I'm downloading a blob from blob storage, my application will hang for at least 30 minutes (this is how long my patience lasted - it probably hangs longer).

For example, this happens if I use the following code (I have not configured any settings on the blob client itself).

...

var blockBlob = container.GetBlockBlobReference("myblob.data");

var blobRequestOptions = new BlobRequestOptions()
    {
        RetryPolicy = new NoRetry(),
    };

using (var stream = new MemoryStream())
{
    blockBlob.DownloadToStream(stream, null, blobRequestOptions);
}

I know that I can configure the MaximumExecutionTime property in BlobRequestOptions, but it seems a bit strange to me that the default behavior is to hang indefinitely if there's a drop in network connectivity. This makes me suspect that I'm missing something basic on how the client is supposed to be used. (There default value for MaximumExecutionTimeout appears to be Infinite).

I also know I can pass in a ServerTimeout, but my understanding is that this is used internally in the Azure Storage service and would't be applicable if there's a network drop.

What I think I'm looking for specifically is a per-request timeout for the HTTP calls made to blob storage. Something like Timeout on a HttpWebRequest.

(I've reproduced my issue in the Azure Storage Client version 9.3.2)

Answer 1

From my understanding of the SDK, the timeout is handled by default on the server side. I did not find anything regarding this on the MSDN, but the Azure Java SDK (using the same HTTP endpoints) says :

The default maximum execution is set in the client and is by default null, indicating no maximum time.

You can check it here : https://azure.github.io/azure-storage-java/index.html?com/microsoft/azure/storage/RequestOptions.html

Look for the setMaximumExecutionTimeInMs method.

Since the timeouts seem to be handled by the server and the default client has not default timeout value, it makes sense that you request never end when you unplug the router because you won't be able to catch the server-sided timeout.

Answer 2

I found that the storage sdk team had indeed acknowledged and addressed this bug in v8.1.3 as seen in the change log: https://github.com/Azure/azure-storage-net/blob/dfc88329b56ef022e38f2d39d709ddc2b41fe6a0/Common/changelog.txt

Changes in 8.1.3 :
- Blobs (Desktop) : Fixed a bug where the MaximumExecutionTime was not honored, leading to infinite wait, if due to a failure, e.g., a network failure after receiving the response headers, server stopped sending partial response.

commit: https://github.com/Azure/azure-storage-net/pull/459/commits/ad8fd6ad3cdfad77cfe23afe16f1f96c04ad90ee

However, your claim is you can reproduce this in 9.3.2. I too, am seeing this issue with 11.1.1. I'm thinking that the bug was not fully addressed.