Вот мой текущий вопрос:
Я предполагаю, что моя проблема (описанная ниже) вызвана переработкой рабочих процессов ASP.NET, согласно приведенным ниже ответам - я использую хранилище сеансов InProc и не вижу особых шансов уйти из-за ограничения для других типов хранилищ, чтобы все объекты сеанса были сериализуемыми. Однако я не могу понять, что заставит рабочий процесс перезапускаться так часто, как я это вижу - насколько мне известно, никаких изменений файлов в каталоге приложения не было, и параметры в IIS кажутся Это означает, что процесс будет повторяться только каждые 1740 минут, что намного реже, чем фактическая потеря сеанса. Итак, теперь у меня вопрос: в каких различных случаях можно повторно использовать рабочий процесс ASP.NET?
Вот мой первоначальный вопрос:
У меня проблема, которую трудно воспроизвести в моем веб-приложении ASP.NET. Приложение имеет одну главную страницу .aspx, которая загружается и инициализирует ряд переменных сеанса. Эта страница использует класс ASP.NET Ajax Sys.Net.WebRequest для многократного доступа к другой странице ASPX, которая использует переменные сеанса для выполнения запросов к базе данных и обновления главной страницы (главная страница никогда не запрашивается повторно).
Иногда после определенного периода использования страницы, вызывающего успешные HTTP-запросы, когда сеанс, созданный на главной странице, должным образом переносится на подстраницу, один из запросов, кажется, вызывает создание нового сеанса ASP.NET - весь сеанс переменные теряются (что приводит к возникновению исключения в моем коде), а новый идентификатор сеанса сообщается на динамически запрашиваемой странице. Это означает, что внезапно главная страница отключается от сервера - что касается сервера, пользователь больше не входит в систему.
Я почти уверен, что это не тайм-аут сеанса - время тайм-аута установлено на что-то нелепое, время, необходимое для того, чтобы это произошло, варьируется, но никогда не бывает достаточно длинным, чтобы вызвать тайм-аут сеанса, и константа Sys.Net.WebRequestsдолжен обновляет таймер сеанса.
Итак, что еще может произойти, что приведет к потере связи HTTP-запросов с сеансом ASP.NET? К сожалению, я не прослушивал сетевой трафик, когда это случилось со мной, иначе я бы проверил, застрял ли файл cookie сеанса ASP.NET или нет.





Рабочий процесс, вероятно, зациклен. http://www.lattimore.id.au/2006/06/03/iis-dropping-sessions/
Из того, что я читал, если ваше приложение ASP.NET использует управление сеансом InProc, то оно действительно будет потеряно, если ваш рабочий процесс будет переработан.
Одним из решений было бы использование StateServer, а не управление сеансом InProc.
Многие вещи могут привести к потере состояния сеанса:
Если состояние сеанса важно для вашего приложения, используйте либо управление состоянием SQL, либо сервер состояний, который поставляется с ASP. СЕТЬ.
Ваше здоровье,
РБ.
Это могло быть вызвано необработанным исключением в фоновом потоке. Это может привести к завершению рабочего процесса ASP.NET. Новый процесс запускается очень быстро, поэтому вы его фактически не замечаете, но все ваши сеансы потеряны.
Вот статья, которая объясняет это намного лучше, чем я могу: Проблемы с необработанными исключениями ASP.NET 2.0
Цитировать:
An unhandled exception in a running ASP.NET 2.0 application will usually terminate the W3WP.exe process, and leave you with a very cryptic EventLog entry something like this:
"EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.1830, P3 42435be1, P4 app_web_ncsnb2-n, P5 0.0.0.0, P6 440a4082, P7 5, P8 1, P9 system.nullreferenceexception, P10 NIL."
Вот статья Microsoft KB, в которой объясняется та же проблема: KB911816 Необработанные исключения приводят к неожиданному завершению работы приложений на основе ASP.NET в .NET Framework 2.0
Я предполагаю, что это будет потребление памяти, но настройте IIS для регистрации повторного использования, и вы будете знать наверняка.
У нас были проблемы с сеансом, когда мы переносили приложение AnkerEx на новый сервер. На новом сервере была установлена операционная система Microsoft Windows Server 2008. и Microsoft Internet Information Services 7. Также на сервере были установлены .NET Framework версий 1.0.3705, 1.1.4322, 2.0.50727, 3.0 и 3.5. Для решения этой проблемы я сделал включение мониторинга работоспособности для события, связанные со временем жизни приложения, в ASP.NET 2.0. Я добавил в web.config:
...
...
<system.web>
...
...
<healthMonitoring>
<rules>
<add name = "Application Events"
eventName = "Application Lifetime Events"
provider = "EventLogProvider"
profile = "Default"
minInterval = "00:01:00" />
</rules>
</healthMonitoring>
...
...
Нам помогает проверить повторное использование AppDomain. Мы можем увидеть это в нашей программе просмотра событий. Ссылка на подробности: http://blogs.msdn.com/rahulso/archive/2006/04/13/575715.aspx
После того, как я закончил добавление в web.config, средство просмотра событий показало мне, что мой приложение перезапускается каждый раз, когда я нажимаю практически на любую ссылку в моем заявление. Из статьи http://blogs.msdn.com/toddca/archive/2005/12/01/499144.aspx i обнаружил, что у ASP.NET новое поведение - если будем делать удаление, например подкаталог корневого каталога приложения, то ASP.NET 2.0 выполнит перезапуск AppDomain.
Проблема была в том, что у меня в web.config была инструкция:
...
<compilation debug = "true" tempDirectory = "c:\AnkerEx\Temporary ASP.NET files">
...
Т.е. ASP.NET компилировал aspx-страницы в папке корня моего приложения. Думаю, он создавал папки, может быть, и удалял некоторые из них. Я удалил Инструкция tempDirectory и приложение начало стабильно работать.
На самом деле ... Когда рабочий процесс перезапускается, исходный процесс продолжает работать и обслуживать запросы для существующих сеансов до тех пор, пока не закончатся оставшиеся сеансы ASP.NET. Все сеансы новый создаются в новом рабочем процессе. Однако классические сеансы ASP теряются.