Сеанс ASP.NET неожиданно заканчивается

Question

У меня очень странная проблема с сессией в ASP.NET 2.0. Система, над которой я работаю, использует переменные сеанса для хранения параметров на объектах (например, вопросы и ответы) для создания отчета. Это экземпляры классов с одинаковыми именами, поэтому они заполняются параметрами следующим образом:

Этот отчет создается на 4 страницах формата aspx. Первый определяет параметры местоположения и даты, второй хранит вопросы и третий хранит ответы. Последний отображает ссылки на сгенерированные отчеты в форматах Excel и HTML. Все переменные данные хранятся в сеансе, и все идет хорошо, до последней страницы, когда происходит что-то вроде Session.Abandon (), происходит событие Session_End и все переменные теряются. Это происходит только один раз в день, для каждого зарегистрированного пользователя при первом использовании отчета, а затем вы можете попробовать целый день десятки раз и больше его не увидите.

Проблема возникает на той же странице ВСЕГДА, а режим сеанса - InProc.

Я уже сделал следующие проверки:

1. Проверяется, были ли какие-либо команды Session.Abandon () или Session.Clear (). Их нет.
2. Проверено время ожидания сеанса, оно установлено на 18 минут, и проблема возникает в любое время, как указано выше, независимо от того, как долго вы используете его в течение 18 минут.
3. Проверено время ожидания формы при Аутентификации. Также установлено 18 минут.
4. Я узнал, что в Server.Transfer () есть ошибка, которая может иногда сбрасывать сеанс и представление состояния, и заменяется на Response.Redirec ()
5. Строго следил за сессией, и все идет хорошо, а когда страница полностью загружена, она просто умирает. Все переменные исчезли, но сессия все еще работает.
6. Насколько мне известно, IIS настроен правильно. У меня нет доступа к нему, но все другие системы работают отлично.
7. Также проанализировали некоторые из вышеупомянутых систем в поисках какой-то подсказки о том, что может происходить, но их файлы web.config очень похожи на тот, который у меня возникает, и никакой специальный код для взаимодействия с сессией не реализован. по-другому.
8. Также задумывался о мониторинге IIS для перезапусков приложений, но я уверен, что он не превышает предельное значение по умолчанию 15. Тем не менее, у меня нет доступа к серверу IIS, и все тесты, выполняемые на моем компьютере, используют ASP. NET Development Server. Проблема возникает на обоих.
9. Проверили возможности повторного использования процесса, такие как изменения .config и asax, изменения в каталоге / on bin, ничего не происходит.

Применяются следующие ограничения:

1. Невозможно изменить режим сеанса, отличный от InProc, из-за политики компании.
2. Генерация отчета "процесс" была создана на 4 страницах. Я не согласен с этим, но не могу повторить его из-за временных и бюджетных ограничений.

Любые мысли или решения полезны. Я буду в курсе любых обновлений и необходимых тестов.

Answer 1

Я хотел бы поблагодарить всех за усилия!

Я и моя команда обнаружили, что происходит по этому делу. Был метод, который удалял временные файлы и каталоги в папке Веб-сайта, вызывая перезапуск и очистку сеанса. Код вычислял дату и время и должен был удалять каталоги каждые 24 часа, поэтому, когда пользователь впервые входит в систему и создает отчет, он удаляет каталог и сбрасывает сеанс.

Answer 2

Несколько предложений:

1. Отладка первого попадания локально и посмотреть, есть ли что-нибудь уникальное в пути.
2. Убедитесь, что первое попадание не вызывает проблем с рабочим процессом
3. Убедитесь, что вы не используете значение сеанса до обратной передачи

Что я думаюпроисходит # 3.Вы устанавливаете значения в сеансе и затем используете их обратно из этого сеанса до обратной передачи, где значение сеанса фактически сохраняется.Поскольку это происходит только с первой попытки, симптомы отражают это подозрение.Если я прав, вы решаете эту проблему, потребляя из того же места, где вы использовали значение сеанса, а не устанавливая сеанс, а затем пытаетесь извлечь из него тот же запрос.

Answer 3

У меня была проблема с сессиями. в моем случае проблема заключалась в максимальном количестве рабочих потоков пула приложений. если вы собираетесь использовать сеанс asp.net по умолчанию, вы должны сделать его 1. или другой поток не может получить сеансы.