使用HttpWebRequest.GetResponse（）时可能导致ThreadAbortException的原因

I'm living in nightmares because of this situation, I have a HttpWebRequest.GetResponse that keeps on giving me a ThreadAbortException, that causes the whole app to go down.

我生活在噩梦中,因为这种情况,我有一个HttpWebRequest.GetResponse,一直给我一个ThreadAbortException,导致整个应用程序关闭。

How can I avoid that, or at least handle it, would using Thread.ResetAbort() be useful in such a case?

我怎样才能避免这种情况,或者至少处理它,使用Thread.ResetAbort()在这种情况下是否有用?

To explain more here is a rough code sample:

在这里解释更多是一个粗略的代码示例:

HttpWebRequest req = (HttpWebRequest)WebRequest.Create("http://someurl.com/");
HttpWebResponse resp = req.GetResponse();

now the last line above throws the ThreadAbortException, it might be because the request timed out which is fine, but I don't want to get a ThreadAbortException inside my ASP.NET 2.0 app because it kills it. The ThreadAborException can't be caught with try/catch, the only way to handle it is using Thread.ResetAbort() which has its own bad effects too, it will keep the thread alive and god only knows for how long.

现在上面的最后一行抛出ThreadAbortException,可能是因为请求超时了,这很好,但我不想在我的ASP.NET 2.0应用程序中获取ThreadAbortException,因为它会杀死它。使用try / catch无法捕获ThreadAborException,处理它的唯一方法是使用Thread.ResetAbort(),它也有自己的不良影响,它会保持线程活着,而且只知道多久。

4 个解决方案

#1

From what you say it seems you are making an outgoing WebRequest to an external resource from within the processing of an incoming request to an ASP.NET application. There are (at least) two timeouts that are relevant here:

根据您的说法,您似乎正在从处理对ASP.NET应用程序的传入请求中将外部WebRequest发送到外部资源。这里有(至少)两个超时相关:

WebRequest.Timeout (default 100000ms = 100s) specifies the timeout for execution of the outgoing WebRequest. If this timeout expires, you should get a WebException - so this isn't your problem.

WebRequest.Timeout(默认为100000ms = 100s)指定执行传出WebRequest的超时。如果此超时到期,您应该获得WebException - 所以这不是您的问题。
The HttpRuntime that is processing your incoming request has an execution timeout: the default value according to MSDN is 110s for .NET 2.0 or later, 90s for .NET 1.x. When this timeout expires, you'll get a ThreadAbortException. It looks like this is what is happening.

处理传入请求的HttpRuntime具有执行超时:根据MSDN的默认值对于.NET 2.0或更高版本为110s,对于.NET 1.x为90s。当此超时到期时,您将收到ThreadAbortException。看起来这就是正在发生的事情。

In .NET 1.x, you'd expect this, because the default HttpRuntime executionTimeout is less than WebRequest.Timeout. In .NET 2.0, you'd expect this with the default timeouts if you have already spent >10s before making the outgoing WebRequest (e.g. if you have more than one outgoing WebRequest from within the same incoming request).

在.NET 1.x中,您会期望这一点,因为默认的HttpRuntime executionTimeout小于WebRequest.Timeout。在.NET 2.0中,如果您在进行传出WebRequest之前已经花费了大于10秒(例如,如果您在同一传入请求中有多个传出WebRequest),则您会期望这具有默认超时。

I would suggest you either:

我建议你:

Reduce the WebRequest.Timeout for outgoing requests, and handle WebException, or

减少传出请求的WebRequest.Timeout,并处理WebException或
If the outgoing requests can really take that long, then increase the httpRuntime execution timeout as described in MSDN.

如果传出请求确实需要那么长时间,则按照MSDN中的描述增加httpRuntime执行超时。

#2

I had this problem with using Response. Check out this article for some workarounds. http://support.microsoft.com/kb/312629

我在使用Response时遇到了这个问题。查看本文以获取一些解决方法。 http://support.microsoft.com/kb/312629

Also take a look at this MSDN documentation in the section for WebException and Remarks. http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.getresponse.aspx

另请参阅WebException和备注部分中的MSDN文档。 http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.getresponse.aspx

This exception can be caught... If you are having trouble detecting the right one, you should try catching a general exception (system.Exception) and from there the stack trace should tell you the specific type (HttpException, WebException, etc) to actually catch.

可以捕获此异常...如果您在检测正确的异常时遇到问题,您应该尝试捕获一般异常(system.Exception),并从那里堆栈跟踪应该告诉您特定的类型(HttpException,WebException等)实际上抓住

#3

Our application threw ThreadAbortException's all the time b/c of Response.Redirect("url") calls. The app never closed, most likely b/c the exception was being caught at some point and remained active.

我们的应用程序在Response.Redirect(“url”)调用的所有时间b / c都抛出了ThreadAbortException。该应用程序从未关闭,很可能是b / c异常在某个时刻被捕获并保持活跃状态。

Incidentally, Response.Redirect("url",false) will prevent the Response from terminating with the exception. Andrew's post links to similar workarounds for different uses of the Response class.

顺便说一句,Response.Redirect(“url”,false)将阻止响应终止异常。 Andrew的帖子链接到Response类的不同用法的类似解决方法。

#4

I've seen both of the problems listed by Andrew and "ForCripesSake".

我已经看到安德鲁和“ForCripesSake”列出的两个问题。

Another possibility for your ThreadAbortException is any code that runs outside the page request lifecycle on the server side, such as HttpModules and HttpHandlers. Any exceptions thrown within a module or handler don't go to the default unhandled exception mechanism in ASP.Net, and can cause the thread to die.

ThreadAbortException的另一种可能性是在服务器端的页面请求生命周期之外运行的任何代码,例如HttpModules和HttpHandlers。在模块或处理程序中抛出的任何异常都不会转到ASP.Net中的默认未处理异常机制,并且可能导致线程死亡。

There are a couple of exceptions that can't be handled easily in ASP.net or the CLR in general, according to this article:

根据这篇文章,有一些例外在ASP.net或CLR中无法轻易处理:

Reliability Best Practices

可靠性最佳实践

Not sure if it applies to the client code you've listed in your question, but it might be related.

不确定它是否适用于您在问题中列出的客户端代码,但可能是相关的。

Hope that helps!

希望有所帮助!

#1