Что может вызвать ThreadAbortException при использовании HttpWebRequest.GetResponse()

Я живу в кошмарах из-за этой ситуации, у меня есть HttpWebRequest.GetResponse, который продолжает давать мне исключение ThreadAbortException, которое заставляет все приложение опускаться.

Как я могу избежать этого или, по крайней мере, справиться с ним, использовать Thread.ResetAbort() в таком случае?

Для более подробного описания здесь приведен пример грубого кода:

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

теперь последняя строка выше выдает исключение ThreadAbortException, возможно, это потому, что время ожидания было прекрасным, но я не хочу получать исключение ThreadAbortException внутри моего приложения ASP.NET 2.0, потому что оно его убивает. ThreadAborException не может быть пойман с помощью try/catch, единственный способ справиться с ним - использовать Thread.ResetAbort(), который также имеет свои собственные плохие эффекты, он будет поддерживать поток в живых, а бог знает, как долго.

Ответ 1

Из того, что вы говорите, кажется, что вы делаете исходящий WebRequest внешним ресурсом из обработки входящего запроса в приложение ASP.NET. Здесь есть (по крайней мере) два тайм-аута:

WebRequest.Timeout(по умолчанию 100000ms = 100s) указывает тайм-аут для выполнения исходящего WebRequest. Если этот тайм-аут истекает, вы должны получить WebException - так что это не ваша проблема.
HttpRuntime, обрабатывающий ваш входящий запрос, имеет тайм-аут выполнения: значение по умолчанию MSDN составляет 110 секунд .NET 2.0 или новее, 90s для .NET 1.x. По истечении этого тайм-аута вы получите исключение ThreadAbortException. Похоже, это то, что происходит.

В .NET 1.x вы ожидаете этого, потому что по умолчанию HttpRuntime executeTimeout меньше, чем WebRequest.Timeout. В .NET 2.0 вы ожидаете, что это будет с таймаутами по умолчанию, если вы уже потратили > 10 секунд до создания исходящего WebRequest (например, если у вас есть несколько исходящих WebRequest из одного и того же входящего запроса).

Я бы предложил вам:

Уменьшить значение WebRequest.Timeout для исходящих запросов и обработать WebException или
Если исходящие запросы могут действительно длиться так долго, увеличьте время ожидания выполнения httpRuntime, как описано в MSDN.

Ответ 2

У меня возникла проблема с использованием Response. Ознакомьтесь с этой статьей для некоторых обходных решений. http://support.microsoft.com/kb/312629

Также ознакомьтесь с этой документацией MSDN в разделе WebException и Notes. http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.getresponse.aspx

Это исключение можно поймать... Если у вас возникли проблемы с обнаружением правильного, вы должны попытаться поймать общее исключение (исключение system.Exception), и оттуда трассировка стека сообщит вам конкретный тип (HttpException, WebException, и т.д.).

Ответ 3

Наше приложение полностью исключало ThreadAbortException b/c Response.Redirect( "url" ). Приложение никогда не закрывалось, скорее всего, b/c исключение попадалось в какой-то момент и оставалось активным.

Кстати, Response.Redirect( "url", false) предотвратит завершение ответа с исключением. Andrew публикует ссылки на похожие обходные пути для разных применений класса Response.

Ответ 4

Я видел обе проблемы, перечисленные Андреем и "ForCripesSake".

Еще одна возможность для ThreadEbortException - это любой код, который выполняется за пределами жизненного цикла запроса страницы на стороне сервера, например HttpModules и HttpHandlers. Любые исключения, брошенные внутри модуля или обработчика, не идут в механизм необработанных исключений по умолчанию в ASP.Net и могут привести к смерти потока.

Есть несколько исключений, которые не могут быть легко обработаны в ASP.net или CLR в целом, согласно этой статье:

Лучшие рекомендации по надежности

Не уверен, что это применимо к коду клиента, указанному в вашем вопросе, но это может быть связано.

Надеюсь, что это поможет!