Server.ClearError()是否阻止IIS快速故障保护?

本文关键字：故障 保护 IIS ClearError 是否 Server | 更新日期: 2023-09-27 18:02:29

Net应用程序中，我们通常试图通过在相关位置捕获异常来处理所有异常，从而为最终用户提供有用的错误消息，但是由于抛出位置的原因，有些异常是不可能捕获的。

这是我们的服务器设置的一个问题，因为我们希望保持IIS快速故障保护按预期工作，并将所有错误写入我们的自定义错误日志。因此，为了避免服务器的意外重置和错误日志泛滥，我在Global.asax.cs中添加了一些代码来抑制某些类型的错误。目前，我们正在研究由IIS本身抛出的两种httpexception，以防止url过长(基于maxUrlLength设置)，并防止错误的WebResource或ScriptResource请求。这些对我们来说是不可能阻止的，因为一些网络爬虫会产生它们。

我感兴趣的是，我很难找到任何地方的信息是:

  1. 引用的httpexception甚至可能导致快速的异常吗重新启动服务器的失败保护?我听说任何未被抓住的异常可能会导致这种情况，但在我看来，这种情况似乎不合逻辑
  2. 如果我在Application_Error()事件中调用Server.ClearError()，是否足以抑制可能导致快速故障保护重启的错误?还是说现在已经太迟了?既然我们已经在
    3. 响应未处理的异常的进程。

Server.ClearError()是否阻止IIS快速故障保护?

快速故障保护(Rapid-Fail Protection，这里是RFP)功能旨在保护系统免受应用程序池和工作进程无法正常启动或经常失败的影响。这些问题可能是由应用程序或IIS工作进程引起的。官方的(尽管是旧的)原因列表可以在这里找到。

  1. 不直接。如果试图处理错误的逻辑失败，则工作进程可能崩溃。这将触发RFP。通常，这不会发生，因为IIS将尝试处理Application_Error中的异常。
  2. 如果您的应用程序已经优雅地处理了Application_Error中的异常，那么它就会停在那里。您的异常在应用程序级别是"未处理的"，但是IIS能够处理它(通常提供"黄屏死机")。因此，工作进程仍然是健康的，不会触发RFP。

我看到一个IIS工作进程在以下情况下崩溃:

  • 递归调用导致无限循环。
  • 系统资源不足，无法处理请求(内存不足或达到内存限制)。
相关文章：