Сессия MVC3 .NET случайным образом теряет значение сеанса и возвращается как ноль

Question

У меня производственная проблема с состоянием сеанса In-Proc.

Наше приложение основано на платформе MVC 3 .NET и интегрировано в наш сайт под управлением Sitecore CMS.

Наши пользователи случайно сталкивались с тем, что «Ссылка на объект не установлена ​​для экземпляра объекта» в процессе приложения.

После обширного ведения журнала и трассировки мы можем заключить, что это было вызвано тем, что объект сеанса возвращает ноль.

Вот некоторые подробности о том, что мы нашли и что мы знаем.

1. Идентификатор сеанса является постоянным для того же пользователя и передал все путь в приложение правильно.
2. Я не верю, что это проблема с кодом, потому что это происходит только в производстве с произвольным интервалом, никогда не происходит в локальной, dev или промежуточной среде.
3. Есть два рабочих сервера, работающих через балансировщик нагрузки.
4. Не является постоянной проблемой сервера, как мы тестировали, спя один из серверов и имея весь трафик на один сервер. Также с помощью регистрации мы могли определить, что пользователь подключается к тому же серверу, но сеанс стал нулевым.
5. Похоже, что это не проблема клиента, потому что они могут успешно пройти приложение, даже если они уже сталкивались с ошибкой.
6. Кажется, это не проблема загрузки трафика или нагрузки на сервер, потому что это происходит в течение дня в случайное время и происходит со случайными пользователями в течение.
7. Кажется, это не вызвано переработкой пула приложений.
8. Это, по-видимому, не вызвано тайм-аутом сеанса, так как мы установили тайм-аут на два часа, и пока мы отслеживаем журнал, пользователи могут испытать эти 5-10 минут в потоке.

Примечание: мы должны использовать состояние сеанса In-Proc из-за нашей CMS Sitecore. Так что изменение дизайна не вариант.

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

В некоторых случаях мы часто наблюдаем возникновение этой проблемы в нашем приложении, когда пользователи перенаправляются с помощью JavaScript (windows.location).

И в областях, где выполняются асинхронные вызовы ajax.

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

Спасибо

Добавлено примечание:

@ Mystere && @ H27Studio, поэтому я также обнаружил кое-что, связанное с sessionID или проблемами сброса сеанса. В некоторых случаях мы обнаруживаем, что при перенаправлении страницы он вызывает два повторяющихся вызова GETS к методу, при первом вызове пропускается sessionID, и случайным образом перенаправляется на один из серверов (это происходит потому, что постоянный сеанс сервера от балансировщика нагрузки основываться на IP-адресе клиента, sessionID и другой информации заголовка, чтобы создать уникальный сеанс для хранения клиента на одном сервере. Это происходит каждый раз во время потока, когда наша страница перенаправления использует window.location.

Это вызовет проблему "Ссылка на объект не установлена ​​.." для клиента, если плохой, без вызова sessionID попадет на тот же сервер. (Вероятно, это связано с тем, что первый неправильный вызов без идентификатора сеанса приводит к тому, что приложение создает новый сеанс, который переопределяет объект исходного сеанса). Таким образом, даже при втором вызове, когда правильный идентификатор сеанса передается в приложение, мы обнаружим, что объект сеанса содержит ноль .

Так что я полагаю, что есть проблема с дублирующим вызовом, который очищает объект сеанса, который не уверен, почему или с чем это вызвано.

Кто-нибудь знает об этом? Спасибо

Обновление: Мы планируем предпринять эти шаги в надежде решить эту проблему.

1. У нас есть проблемы в областях, где были сделаны вызовы Async Ajax, поэтому мы планируем удалить функцию Async и позволить ей работать синхронно Ajax.
2. У нас есть проблемы, когда происходит перенаправление JavaScript в Windows.location. Мы создали альтернативный метод с использованием обратной передачи в надежде исправить проблему в этой области.
3. Другие области, которые не связаны с одной из вышеупомянутых проблем, все еще находятся в воздухе.

Эффект от изменений будет опубликован после того, как мы развернем его в производство.

Спасибо за все комментарии.

Answer 1

После нескольких месяцев поиска и отладки, я думаю, мы наконец пришли к выводу.Кажется, есть ошибка с тайм-аутом сеанса роботов Sitecore Analytics.Сначала мы замечаем, что всякий раз, когда случайный сеанс был потерян из-за преждевременного тайм-аута сеанса, мы замечаем, что этот сеанс был настроен на время ожидания 1 мин вместо 120 мин.

После поиска во всех файлах конфигурации, которые мы заметилито, что Sitecore Analytic.Robots.SessionTimeout было единственным значением времени ожидания, установленным на 1 мин.

Увеличив это значение, оно решило нашу проблему времени ожидания сеанса.

Таким образом, основная проблема заключается в том, что Sitecore Analytics ошибочноидентифицируя некоторый сеанс посетителя как сеанс робота и переназначая их время ожидания на 1 мин.Это, вероятно, ошибка, чтобы сообщить.

Обновление: Ответ от Sitecore:

Sitecore CMS была разработана для использования с технологией ASP.NET WebForms.При использовании веб-форм обнаружение ботов зависит от элемента управления страницы.Естественно, что вы не можете использовать его в приложении ASP.NET MVC, но есть простое решение - поместите в элемент следующий код:

<%
if (Context.Diagnostics.Tracing || Context.Diagnostics.Profiling)
{
  Response.Write("<!-- Visitor identification is disabled because debugging is active. -->");
}
else if (Tracker.IsActive && (Tracker.Visitor.VisitorClassification == 925))
{
  Response.Write("<link href=\"/layouts/System/VisitorIdentification.aspx\"    rel=\"stylesheet\" type=\"text/css\" />");
}
%>

Answer 2

Я думаю, что вашей проблемой могут быть асинхронные ajax-вызовы, на которые вы ссылаетесь.Недавно я прочитал статью Дэвида Хейдена, в которой рассказывалось о проблемах с одновременными запросами AJAX в одном сеансе, вызывающих проблемы.Это что-то, чтобы посмотреть в любом случае.Надеюсь, это поможет.

http://davidhayden.com/blog/dave/archive/2011/02/09/SessionLessControllersMvc3.aspx

Он говорит об этом прямо в конце поста.