頁面渲染超時會發生什麼？

我有一個問題，我不能完全找到答案......頁面渲染超時會發生什麼？

如果你有一個ASP.Net頁面，需要更長的時間比請求超時渲染上發生了什麼過程？ Web服務是否會中止它？

假設我正在將XML寫入ASP.Net頁面中的響應流，並超時調用我的GenerateXML方法。我的方法調用會發生什麼？它是否完成，但Web服務器報告超時？還是中止？

我大概可以寫一個測試來看看我自己的結果，但我覺得可能還有更多。

2010-02-19 Jeff

讓我們來澄清一下：您的問題（1）會話超時（2）請求超時至少有兩個超時。最常見的情況是請求超時 - 因爲客戶端不想在服務器活動之前等待幾分鐘。並且像往常一樣請求生命期比會話少。在這種情況下，服務器以通常的方式終止請求 - 通過提高ThreadAbortException。即使一切正常，也會引發此異常，只是爲了終止請求處理。

當會話結束時 - 客戶端甚至不應該知道它。只有當你有自動化客戶端將被重定向到登錄頁面。但服務器代碼可能會丟失會話中存儲的數據。

來源

2010-02-19 22:28:09 Dewfy

那麼我的頁面請求（因此GenerateXML方法）正在執行的線程被ThreadAbort取下呢？處理這種情況的最佳方法是什麼？我正在生成然後緩存XML，但如果它總是在第一次生成時超時，那麼它永遠不會被緩存。 – Jeff 2010-02-19 22:41:09

@Jeff：我總是討厭像這樣得到答案，但是如果你的頁面渲染器需要*那麼長，問題在於頁面渲染，而不是IIS處理會話管理的方式，所以這是你應該改進的地方...... – Treb 2010-02-19 22:50:47

我想的很多。這意味着更多的工作來解決這個問題。我只需要考慮頁面請求過程來證明自己。 – Jeff 2010-02-19 22:56:25

由於渲染過程不知道會話超時本身，我的假設是渲染完成沒有任何問題。只是當用戶在渲染的頁面上執行一個操作並將其發送回服務器時，tiemout才能實現。

我現在無法通過任何證據來支持這一點，但對我而言，這是最合乎邏輯的行爲。除此之外，在渲染過程中需要額外的超時檢查，這會花費CPU時間（=金錢），但不會以任何方式提高會話安全性。

來源

2010-02-19 22:26:49 Treb

頁面渲染超時會發生什麼？

回答

相關問題