2

我正在測試連接到Azure Blob存儲的我的WPF應用程序,以使用TPL(任務)下載一堆圖像。 預計在Live環境中,在部署的位置會有高度瞬時的互聯網連接。Azure StorageClient瞬態連接測試 - 掛起

我已經設置重試政策和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 ... 
    } 
} 

回答

1

你的問題主要和造成的,因爲Azure存儲客戶端庫使用文件流類下面是爲什麼API掛起與Windows Azure Blob客戶端庫不直接相關。通過網絡直接調用文件流式API,當網絡電纜突然移除時,您可以看到完全相同的行爲,但正常移除網絡將返回不同的行爲。

如果您在互聯網上搜索,您會發現流類沒有檢測到網絡丟失,這就是爲什麼在您的代碼中,您可以檢查網絡斷開事件,然後停止後臺流線程。

+0

感謝您的幫助@AvkashChauhan。當你說'優雅地移除網絡'時我不明白。我如何測試這樣的事件? –

+0

我正在考慮實現的是:只有在連接沒有恢復的情況下,在等待X個時間量(這比我的服務器超時更多的陰影)之後,啓動另一個網絡斷開連接檢測的後臺任務並取消下載任務。 –

2

我相信Avkash是正確的。此外,要清楚,你基本上從來沒有看到網絡刪除錯誤,所以沒有太多的測試點。根據您處理存儲帳戶的方式,您會看到大量連接被拒絕,衝突,資源缺失,只讀帳戶,限制,訪問被拒絕,甚至DNS解析失敗。你應該測試這些。

這就是說,我建議你根本不要使用RetryPolicy和blob或table存儲。對於您實際遇到的大多數錯誤,它們不能重試(例如404,409,403等)。當你有一個重試策略時,默認情況下會在接下來的2分鐘內再嘗試4次。例如重試錯誤憑證沒有意義。

你可以更好地處理錯誤並有選擇地重試自己(超時和節流是唯一有意義的事情)。

+0

感謝您的提示@dunnry。該應用程序將在移動中用於筆記本電腦,通過3G加密狗(來自移動運營商)或智能手機上的WiFi連接至互聯網。預計在移動過程中,信號強度會波動並常常導致連接損耗。我試圖通過拉網線來模擬這種連接丟失。至於您關於可重試錯誤的提示,我已經考慮並處理了我自己的「重試策略」方法。 –