wpf - Azure StorageClient 瞬时连接测试 - 挂起

Question

我正在测试连接到 Azure Blob 存储的 WPF 应用程序，以使用 TPL(任务)下载一堆图像。预计在实时环境中，部署位置将会有高度短暂的互联网连接。

我在 BlobRequestOptions 中设置了重试策略和超时，如下所示:

//Note the values here are for test purposes only
//CloudRetryPolicy is a custom method returning adequate Retry Policy
// i.e. retry 3 times, wait 2 seconds between retries
blobClient.RetryPolicy = CloudRetryPolicy(3, new TimeSpan(0, 0, 2));

BlobRequestOptions bro = new BlobRequestOptions() { Timeout = TimeSpan.FromSeconds(20) };
blob.DownloadToFile(LocalPath, bro);

上述语句位于后台任务中，按预期工作，并且我在后台任务和延续任务中进行了适当的异常处理。

为了测试异常处理和我的恢复代码，我通过拔出网线来模拟互联网断开连接。我已经在 UI 线程上连接了 System.Net.NetworkChange.NetworkAvailabilityChanged 事件的方法，我可以按预期检测连接/断开连接并相应地更新 UI。

我的问题是:如果我在下载文件时拔出网络电缆(通过 blob.DownloadToFile)，后台线程就会挂起。它不会超时，不会崩溃，不会抛出异常，什么都没有!!!在我撰写本文时，我已经等待了大约 30 分钟，并且没有发生与后台任务相关的响应/处理。

如果我拔掉网线，在下载开始之前，执行将按预期进行。即我可以看到重试发生、异常引发并提前传递等等。

有人经历过类似的行为吗？有什么技巧/建议可以克服这种行为/问题吗？

顺便说一句，我知道我可以在检测到网络连接丢失时取消下载任务，但我不想这样做，因为网络连接可以在超时时间内恢复，并且下载过程可以继续从它被中断的地方。我已经测试了这个自动恢复并且效果很好。

下面是我的代码结构的粗略指示(语法上不正确，只是流程指示)

btnClick()
{
  declare background_task
  attach continuewith_task to background task
  start background task
}

background_task()
{
  try
  {
    ... connection setup ... 
    blob.DownloadToFile(LocalPath, bro);
  }
  catch(exception ex)
  {
     ... exception handling ....
     // in case of connectivity loss while download is in progress
     // this block is not getting executed
     // debugger just sits idle without a current statement
  }
}

continuewith_task()
{
  check if antecedent task is faulted
  {
     ... do recovery work ...
     // this is working as expected if connectivity is lost
     // before download starts
     // this task does not get called if connectivity is lost
     // while file transfer is taking place
  }
  else
  {
     .. further processing ...
  }
}

Answer 1

我相信 Avkash 是正确的。另外，需要明确的是，您基本上永远不会看到网络删除错误，因此对其进行测试没有太多意义。您将看到大量连接被拒绝、冲突、资源丢失、只读帐户、限制、访问被拒绝，甚至 DNS 解析失败，具体取决于您处理存储帐户的方式。您应该测试这些。

话虽这么说，我建议您根本不要将 RetryPolicy 用于 blob 或表存储。对于您实际遇到的大多数错误，它们一开始就不可重试(例如 404、409、403 等)。当您制定重试策略时，默认情况下，它实际上会在接下来的 2 分钟内再尝试 4 次。例如，重试错误的凭据是没有意义的。

您最好简单地处理错误并自己有选择地重试(超时和限制是这里唯一有意义的事情)。