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

Question

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

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

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

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

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

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

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

У меня есть теория, которая может иметь какое-то отношение к блокировке сеанса или к повреждению от одновременных попыток доступа.

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

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

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

Благодаря

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

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

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

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

У кого есть ключ к этому вопросу? Спасибо

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

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

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

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

Answer 1

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

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

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

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

Update: Ответ 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

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

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

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