2009-12-23 6 views
0

В течение последних двух дней моих праздников X-mas я боролся с UnathorizedAccessException при попытке прочитать файл XML на удаленном общем ресурсе через мое приложение ASP.NET, используя реализацию IHttpAsyncHandler a долго с IRequiresSessionState.IHttpAsyncHandler вызывает UnathorizedAccessException

После многого головного убоя и заключения о том, что код OUTSIDE обработчик работал безупречно (см .: доступ предоставлен), я подумал, что это может быть проблема с потоками, поэтому я изменил IHttpAsyncHandler на IHttpHandler, и проблема исчезла.

Что меня беспокоит вот, что для целей тестирования, я фактически не использовать, если реализация IHttpAsyncHandler (следовательно, я не использовал BeginProcessRequest и EndProcessRequest -.. Только синхронизация версии, ProcessRequest

Может кто-нибудь пытается объяснить эту проблему?

Есть несколько полезных вопросов при использовании обработчика асинхронно, поскольку я мог предварительно кэшировать значения, которые будут доставлены позже в приложении, но для этого мне нужно получить передавать проблемы безопасности, которые, по-видимому, проявляются только при внедрении IHttpAsyncHandler.

Заранее благодарю вас за вашу помощь - и счастливые праздники :-)

ответ

1

Инфраструктура ASP.NET вызывает асинхронный обработчик по-разному (независимо от того, является ли им действительно асинхронным). Возможно ли, что вы полагались на олицетворение доступа к сетевому ресурсу? Я предполагаю, что нужный WindowsIdentity не перетекает в поток threadpool, который фактически обрабатывал запрос (я никогда не пытался использовать олицетворения + обработчик async, но в прошлом я столкнулся с другими проблемами потока потока).

Независимо от того, что истинный обработчик асинхронного сканирования дорого реализуется правильно. Если вы не строите поверх многих асинхронных инфраструктур (async-файл, клиент async-DB и т. Д.), Это не делает вам ничего хорошего (на самом деле, даже в лучших случаях, обработчики async повреждают raw представление). Я бы посмотрел, действительно ли ваша производительность действительно оправдывает дополнительные проблемы и накладные расходы обработчика async (например, вам нужно обслуживать еще много параллельных запросов, чем потоки в процессе и т. Д.).

+0

Благодарим вас за ответ. Проблема заключается в том, что мне нужно найти некоторые возможные внешние URI на уровне HEAD, чтобы разрешить некоторую информацию о них. Это в синхронном вопросе может занять много времени, поэтому я думал об асинхронном аскере. Возможно, мне придется подумать, если преимущества меньше по сравнению со временем его реализации. Я не делаю никакого олицетворения; пока я полагаюсь на настройки, применяемые к AppPool, где по умолчанию используется ApplicationPoolIdentity. –