Azure Blob Storageに接続する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 ...
}
}