WCF服務掛在SendResponse

我有一個WCF REST服務，託管在IIS中。客戶（主要是瀏覽器）一直在抱怨偶爾掛起。我終於親自體驗了這一點，並能夠從服務器獲取一些調試信息。我從IIS管理控制檯抓取了以下截圖。WCF服務掛在SendResponse

Hanging Requests

顯然，這些請求都被周圍的時間太長了。

雖然這些請求被掛起，但服務器能夠處理其他請求就好了。我幾次回收應用程序池，沒有明顯效果。在此期間，來自我的瀏覽器的任何請求都會掛起，然後由瀏覽器超時。我的同一臺計算機上的其他瀏覽器能夠連接到相同的服務，沒有任何問題。我也開除了Fiddler，然後通過Fiddler從我的「掛斷」瀏覽器發出請求。當我關閉Fiddler時，瀏覽器再次「掛起」。當我最終關閉瀏覽器時，連接消失了。

一個潛在的重要問題是：您不能在屏幕截圖中分辨出來，但請求都掛在發送二進制流（照片&視頻）到客戶端的呼叫上。在封面下，我打開Azure Blob存儲流（使用OpenRead（）），然後從我的函數返回相同的流。所以我正在通過網絡讀取數據，並將數據傳輸到另一端的網絡。

那麼這裏發生了什麼？我怎樣才能防止連接掛起，或者至少讓他們在某個合理的時間點超時？

更新：看起來瀏覽器可能是問題。如果頁面上有一個HTML5 <video>元素，並且視頻足夠大，那麼瀏覽器似乎會打開一個連接以下載文件並將其永久打開。我只有約75％的確定，但如果/當我找到肯定的時候，我會在這裏添加更新。

來源

2012-05-04 Brian Reischl

事實證明，問題完全在瀏覽器中。我有一些頁面，其中有多個<video>標籤。事實證明，在某些情況下，瀏覽器將爲每個視頻打開一個連接，並將其保持打開狀態，直到視頻播放完畢。

至少有幾個不同的瀏覽器端解決辦法：

在<video>標籤添加preload="none"屬性。
默認情況下不顯示視頻。而是顯示圖像，然後在用戶點擊該標籤時動態呈現<video>標記。

另外，我向那些迴應此事的人道歉。我只是沒有給你足夠的信息來找到正確的答案，所以你從來沒有真正有機會。

來源

2012-05-08 19:01:10

下次發生這種情況時，運行同一瀏覽器的單獨實例並啓動其他一些瀏覽器（Firefox，Chrome，IE等）。您需要確定問題是否與特定瀏覽器有關。

我想你已經在瀏覽器中發現了一個bug。 Fiddler的插入暫時解決它的事實表明它必須處理通過特定協議棧進行的連接狀態管理。如果是這樣的話，那麼你會發現問題在某個特定瀏覽器的實例中是本地的。

除了向瀏覽器供應商報告外，您無法做任何事情。

如果你能證明這個錯誤只在IE和Azure之間出現，那麼這個錯誤可能是由Azure的一些怪癖觸發的，在這種情況下，因爲這是單個供應商問題，你得到解決方案的機會從「「地獄中的雪球」到「不要屏住呼吸」。

來源

2012-05-04 04:06:50

我其實是這麼做的。最初的凍結是在Chrome中，但在同一臺機器上的Firefox和IE9都很好。我還有其他用戶在這些瀏覽器中報告錯誤，這導致我相信這不是瀏覽器特定的問題。 –

Fidler是一個代理服務器，它將注入自己的過程而不是您現有的代理服務器。這使我相信您（和其他人）在自動代理設置或其他代理設置相關問題方面存在問題。

來源

2012-05-04 04:50:17

我們沒有自動代理。即使我們做了，似乎其他瀏覽器也會受到影響。另外，我已經向處於完全獨立網絡中的用戶報告了這種情況。 –

我的回答是基於這樣一個事實，即回收應用程序池連接不會立即終止。如果在服務和客戶端之間存在一些中間人（如負載平衡器），則控制數據流可能是原因。 –

好吧，我明白你要去哪裏。服務器前有一個負載均衡器。但瀏覽器無法向該服務器發送更多請求，我認爲這意味着從服務器到瀏覽器的連接始終處於打開狀態。 –