dot-netasp.netmultithreading

Почему мое приложение asp.net выдает исключение ThreadAbortException?

просмотры: 12.2K

Это очевидный вопрос:

Почему эта штука попадает в мои пробные уловы, даже если все в порядке?

Почему это появляется в моем журнале сотни раз?

Я знаю, что это новенький вопрос, но если этот сайт получит рейтинг в поиске и привлечет новичков, мы должны спросить их.

Источник

Ответов (5)

Решение

Вероятно, это происходит из-за вызова Response.Redirect. Проверьте эту ссылку для объяснения:

http://dotnet.org.za/armand/archive/2004/11/16/7088.aspx

(В большинстве случаев вызов Response.Redirect (url, false) устраняет проблему)

Источник

Наиболее частой причиной исключения ThreadAbortException является вызов Response.End, Response.Redirect или Server.Transfer . Microsoft опубликовала несколько предлагаемых функций, которые следует использовать вместо этих функций.

Источник

Причина, по которой Response.Redirect выдаст это исключение, заключается в том, что asp.net внутренне реализует этот API с помощью Thread.Abort (). Когда этот метод вызывается, генерируется специальное исключение ThreadAbortException, которое не будет поглощено никаким блоком catch. Он будет повторно брошен в конце каждого блока catch.

Источник

Как говорили другие, это происходит, когда вы вызываете Response.End () (что происходит, когда вы вызываете Response.Redirect без передачи false в качестве второго параметра). Это работает так, как задумано; обычно, если вы вызываете Response.Redirect, вы хотите, чтобы перенаправление происходило немедленно. См. Это для получения дополнительной информации:

Response.Redirect и ThreadAbortException

Источник

Зная, что существует (по крайней мере) три API, которые используются внутри компании Thread.Abort, я хотел бы более практично ответить, как решить, что с этим делать.

Для нас эта ошибка начала регистрироваться внезапно. Что изменилось? Мы исправили ошибку в некоторой процедуре базы данных, которая имела дело с картами сайта.

Журналы log4net показали, что заголовок X-Forwarded-For (мы за NLB) был IP-адресом робота Googlebot, 66.249.78.x, что подтвердило мою теорию об изменении карты сайта, которое привело к тому, что Google сканирует наш сайт более агрессивно в поисках изображений.

Первым делом нужно было выяснить, почему только робот Googlebot может вызвать эту проблему. Ни один другой клиент не запускал какой-либо путь кода Response.Redirect или что-то еще.

Итак, в HttpApplication.Error обработчике я добавил код для регистрации дополнительных подробных выходных данных со всеми заголовками и большей частью данных в HttpResponse и HttpContext извергнутых в журнал.

Это позволило мне увидеть, что проблема заключалась в том, что робот Googlebot использует строку пользовательского агента iPhone, и, вооружившись этим, я смог выполнить поиск в базе кода для «iPhone» и придумал:

private void CheckIPhoneAccess() { ... }

И для этого используется перенаправление.

Что с этим делать?

Что ж, для этой устаревшей кодовой базы не стоит ретропатчить все Response.Redirect вызовы, поэтому я собираюсь снизить уровень ведения журнала ThreadAbortException для приложения.

Я изменю поведение мобильного сканера Googlebot, которое не приведет к «лжи» о том, что наш сайт обслуживает для мобильных устройств, поскольку он перенаправляет только при первом обращении, впоследствии он считывает файл cookie и показывает изображение. Робот Googlebot не кэширует этот файл cookie.

Это не идеально, но сайт нужно перестроить. вероятно, другой командой, использующей Scala или что-то в этом роде, так что с практической точки зрения я думаю, что это хороший выбор. Я добавлю комментарии и, возможно, вернусь к проблеме позже, создаю Response.SafeRedirect расширение, которое инкапсулирует этот совет:

Почему Response.Redirect вызывает исключение System.Threading.ThreadAbortException?

Люк

Источник