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

【问题标题】：Azure Blob Storage .NET client request timeoutAzure Blob 存储 .NET 客户端请求超时
【发布时间】：2019-03-21 21:02:06
【问题描述】：

我试图了解在 Azure Storage .NET 客户端中处理网络错误的行为。简而言之，我的问题是：

如果我在从 blob 存储下载 blob 时拔出网线，我的应用程序将挂起至少 30 分钟（这是我的耐心持续的时间 - 它可能挂起的时间更长）。

例如，如果我使用以下代码（我没有在 blob 客户端本身上配置任何设置），就会发生这种情况。

...

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

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

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

我知道我可以在 BlobRequestOptions 中配置 MaximumExecutionTime 属性，但如果网络连接中断，默认行为是无限期挂起，这对我来说似乎有点奇怪。这让我怀疑我遗漏了一些关于客户端应该如何使用的基本内容。（MaximumExecutionTimeout 的默认值似乎是 Infinite）。

我也知道我可以传入 ServerTimeout，但我的理解是，这是在 Azure 存储服务内部使用的，如果出现网络中断，则不适用。

我认为我正在寻找的是针对对 blob 存储进行的 HTTP 调用的每个请求超时。类似于 HttpWebRequest 的超时。

（我在 Azure 存储客户端 9.3.2 版中重现了我的问题）

【问题讨论】：

标签： c# .net azure timeout azure-blob-storage

【解决方案1】：

根据我对 SDK 的理解，超时默认是在服务器端处理的。我在 MSDN 上没有找到任何相关信息，但 Azure Java SDK（使用相同的 HTTP 端点）说：

默认最大执行时间在客户端设置，默认为null，表示没有最大时间。

你可以在这里查看：https://azure.github.io/azure-storage-java/index.html?com/microsoft/azure/storage/RequestOptions.html

寻找 setMaximumExecutionTimeInMs 方法。

由于超时似乎由服务器处理，并且默认客户端没有默认超时值，因此在拔下路由器时请求永不结束是有道理的，因为您将无法捕获服务器端超时.

【讨论】：

本文档适用于 java。 C#中对应的属性是上面提到的ServerTimeout。
是的，我知道，但正如我所说，我在默认超时中找到的唯一参考是在 Java 文档中，MSDN 没有提到它。我可以假设两个平台上的行为是相同的。这将解释您的问题。
对应的属性不是ServerTimeout，而是你也提到的MaximumExecutionTime。所以我认为这应该是解决方案，并且您不会像担心的那样错过一些基本的东西

【解决方案2】：

我发现 storage sdk 团队确实承认并解决了 v8.1.3 中的这个错误，如更改日志所示： 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.

提交：https://github.com/Azure/azure-storage-net/pull/459/commits/ad8fd6ad3cdfad77cfe23afe16f1f96c04ad90ee

但是，您声称可以在 9.3.2 中重现此内容。我也看到了 11.1.1 的这个问题。我认为这个错误没有完全解决。

【讨论】：