ThreadAbortException в дескрипторе утечки ASP.Net 4?

Иногда, если наш файловый сервер работает медленно и страница не завершается по тайм-ауту, ASP.Net выдает исключение ThreadAbortException. Если это происходит внутри Win32Native.CreateFile, дескриптор файла остается заблокированным до тех пор, пока мы не выполним iisreset.

Является ли это недостатком .NET? Можем ли мы что-нибудь сделать с этим, за исключением плохих идей, таких как увеличение времени ожидания до какого-то гигантского числа... Я не думаю, что ThreadAbort.Reset поможет, потому что ущерб уже нанесен, и я даже не вернул дескриптор файла из FileStream, чтобы закрыть его самостоятельно.


в Microsoft.Win32.Win32Native.CreateFile (String lpFileName, Int32 dwDesiredAccess, FileShare dwShareMode, SECURITY_ATTRIBUTES securityAttrs, FileMode dwCreationDisposition, Int32 dwFlagsAndAttributes, IntPtr hTemplateFile)

в Microsoft.Win32.Win32Native.SafeCreateFile (String lpFileName, Int32 dwDesiredAccess, FileShare dwShareMode, SECURITY_ATTRIBUTES securityAttrs, FileMode dwCreationDisposition, Int32 dwFlagsAndAttributes, IntPtr hTemplateFile)

в System.IO.FileStream.Init (путь String, режим FileMode, доступ к FileAccess, права Int32, логическое значение useRights, общий доступ к FileShare, размер буфера Int32, параметры FileOptions, SECURITY_ATTRIBUTES secAttrs, String msgPath, логическое значение bFromProxy, логическое значение useLongPath)

в System.IO.FileStream..ctor (путь String, режим FileMode, доступ к FileAccess, общий ресурс FileShare, размер буфера Int32, параметры FileOptions, String msgPath, логическое значение bFromProxy)

в System.IO.FileStream..ctor (путь строки, режим FileMode)


person ss2k    schedule 25.04.2012    source источник


Ответы (2)


Похоже, вы также отправили этот вопрос в Microsoft Connect и не обновили здесь свой ответ:

http://connect.microsoft.com/VisualStudio/feedback/details/739044/threadabortexception-in-asp-net-4-during-new-filestream-leaking-file-handle

Вот ответ от Microsoft:

Выполнение длительных операций в синхронных запросах в ASP.NET не рекомендуется. Если вы достигли периода ожидания, вы можете просто увеличить настроенное время ожидания запроса или перейти к использованию асинхронных запросов, которые не истекают во время выполнения асинхронных операций и, следовательно, не вызывают исключений прерывания потока.

Я предполагаю, что прерывание потока (или любое асинхронное исключение в этом отношении) может и в конечном итоге сделает это.

Но похоже, что фреймворк будет использовать SafeFileHandle внутри при открытии файла, поэтому он должен быть закрыт сборщиком мусора, когда он неторопливо доберется до него.

person Nick Whaley    schedule 30.07.2013
comment
Их ответ был бесполезен, учитывая, что это был тайм-аут вне моего контроля. Неторопливое выполнение этой части не так хорошо работает с заблокированным файлом в загруженном веб-приложении... - person ss2k; 21.10.2013
comment
@ss2k Понятно. Никогда не говорил, что это хороший ответ, но это правда: асинхронные исключения небезопасны. Вероятно, вам следует рассмотреть возможность запуска таймера на рассматриваемой странице, который может отменить запрос более безопасным способом, когда он не будет в середине CreateFile. - person Nick Whaley; 31.12.2013

Правильно ли вы закрываете файл в своем коде, используя close в своем предложении finally или используя подход using?

person tymtam    schedule 03.07.2013
comment
Да, и это происходит во внутреннем коде фреймворка, а также в файловых зависимостях для кеша. - person ss2k; 13.02.2014