2015-07-13 82 views
1

在我們的ASP.Net應用程序,我們通常試圖通過抓住他們有關的地方給最終用戶有用的錯誤信息來處理我們所有的例外,但有些例外,我們不可能趕上他們被拋出的地方。不Server.ClearError()防止IIS快速失敗保護

這是一個問題,我們的服務器設置,因爲我們希望保持快速IIS失敗保護工作如期進行,被寫入到我們的自定義錯誤日誌中的所有錯誤。所以爲了避免意外重置服務器和氾濫我們的錯誤日誌,我在Global.asax.cs中添加了一些代碼來抑制某些類型的錯誤。目前我們正在研究IIS本身拋出的兩種HttpExceptions,以防止太長的URL(基於maxUrlLength設置),並防止有錯誤的WebResource或ScriptResource請求。這些對於我們來說是不可能的,因爲一些網絡爬蟲生成它們。

什麼我想知道,這是我很難找到的任何地方的信息是:

  1. 可引用HttpExceptions甚至可能導致快速 失敗保護重新啓動服務器?我被告知,任何未被捕獲的異常都可能導致異常,但對我來說異常的這種異常應該能夠引起異常似乎不合邏輯。
  2. 如果我在Application_Error()事件中調用Server.ClearError(),是否足以抑制可能導致快速失敗保護重啓的錯誤? 還是現在已經太晚了?由於我們已經在響應未處理的異常的 進程中。

回答

0

快速失敗保護(此處爲RFP)功能旨在保護系統免受應用程序池和工作進程的啓動不正常或失敗的情況。這些問題可能是由您的應用程序或IIS工作進程引起的。官方(雖然舊)的原因列表可以找到here

  1. 不是直接。如果嘗試處理錯誤的邏輯失敗,則工作進程可能會崩潰。這將觸發RFP。通常,這不會發生,因爲IIS將嘗試處理Application_Error中的異常。
  2. 如果您的應用程序已優雅地處理了Application_Error中的異常,那麼它會在此處停止。你的例外在應用程序級別是「未處理的」,但IIS能夠處理它(通常服務於「黃色死亡屏幕」)。因此,工作流程仍然健康,RFP不會被觸發。

我看到一個IIS工作進程崩潰在下列條件下:在一個無限循環

  • 遞歸調用的結果。
  • 系統資源不足以處理請求(達到內存不足或內存限制)。