Сеанс ASP.NET потерян, но только для одного конкретного пользователя

У меня есть приложение ASP.NET, которое работает на двух серверах с балансировкой нагрузки. Все работает нормально, кроме одной группы клиентов. Все эти клиенты приходят из одной и той же компании. Случайным образом возникает необработанная ошибка NullReferenceException. Это происходит в случайное время в случайных местах. Кажется, что сессия просто закончилась. поскольку это происходит только для определенной группы пользователей, я должен предположить, что это как-то связано с их средой. Я видел, как пользователи приходят с IE6, IE7, IE8 и FF, и ошибка возникает во всех случаях.

Я не уверен на 100%, как решить эту проблему. У кого-нибудь есть идеи?

РЕДАКТИРОВАТЬ: для сеанса установлено значение «InProc».

<sessionState mode="InProc" cookieless="false" timeout="20" />

asp.net session nullreferenceexception web-farm
person HitLikeAHammer    schedule 08.07.2010    source источник
comment
Какой механизм балансировки нагрузки вы используете?   -  person Neil Moss    schedule 09.07.2010

Ответы (4)


arrow_upward
1
arrow_downward

Сеанс InProc не распределяется между серверами, поэтому создается впечатление, что эта группа пользователей перемещается с одного сервера на другой, а остальные нет. Возможно, ваш балансировщик нагрузки пытается добиться закрепления сеансов, используя что-то вроде IP-адреса или чего-то еще, и эта организация блокирует эту информацию.

person FinnNk    schedule 08.07.2010
comment
Что-то вроде этого может быть проблемой. Предполагая, что это так, могу ли я что-нибудь сделать со стороны приложения, чтобы исправить это? - person HitLikeAHammer; 09.07.2010
comment
Проще всего настроить один из других режимов состояния сеанса (оба могут совместно использоваться серверами). Если это невозможно из-за ограничений на то, что вы можете делать на серверах/базе данных, вам придется либо хранить данные пользователя, а затем извлекать их самостоятельно на основе какого-то ключа, который передается в скрытых полях формы или URL-адреса - или вы могли бы попытаться сделать эти страницы полностью безгражданскими. Любой из этих вариантов, вероятно, потребует больших усилий, если вы уже используете сеанс во многих местах, плюс дополнительные проблемы с безопасностью и т. д. - person FinnNk; 09.07.2010

arrow_upward
1
arrow_downward

Я связался с пользователем, у которого была проблема. Я попросил его открыть браузер, зайти на сайт whatsmyip.org и сказать мне, что он говорит о его IP-адресе. Затем я попросил его несколько раз обновить экран. Ну, разве вы не знали, что IP-адрес изменился. Он продолжал переключаться между двумя разными IP-адресами. Это был IP-адрес не его машины, а двух разных прокси. Очевидно, что каждый запрос может исходить от одного или другого.

Наш балансировщик нагрузки (что-то под названием Zeus — я не сетевой парень) был настроен на установку сходства сеансов (также известного как липкие соединения) с использованием IP-адресов. Мы изменили настройки, чтобы балансировщик нагрузки сбрасывал cookie и использовал его для поддержания сеанса, и теперь все работает правильно.

person HitLikeAHammer    schedule 23.07.2010

arrow_upward
0
arrow_downward

Если вы используете SQL для хранения состояния сеанса, убедитесь, что все серверы в ферме обращаются к одной и той же базе данных SQL — я уже был пойман на этом раньше, и потребовалось довольно много времени, чтобы разобраться!

Редактировать: на самом деле вам может понадобиться установить значение StateServer, поскольку вы работаете в веб-ферме. См. это о режимах состояния сеанса из MSDN.

person Matthew Dresser    schedule 08.07.2010
comment
Сессия настроена на InProc (вопрос изменен), спасибо. - person HitLikeAHammer; 09.07.2010

arrow_upward
0
arrow_downward

Если ваша балансировка нагрузки основана на направлении каждого обращения к наименее загруженному серверу, то InProc не будет работать. вам нужно будет использовать режимы StateServer или SQLServer.

Представьте, что первое обращение клиента направлено на сервер А, который запускает новый сеанс на сервере А. Второе обращение того же клиента может перейти на сервер Б, предоставив файл cookie сеанса с сервера А, который сервер Б не распознает.

Если у вас «залипающая» (или привязка к клиенту) балансировка нагрузки, при которой первое попадание назначается наименее загруженному серверу, а последующие обращения из того же сеанса направляются на тот же сервер, то InProc все равно должен работать.

person Neil Moss    schedule 08.07.2010
comment
Мы используем липкие соединения. Тот факт, что это только для определенной группы пользователей, заставляет меня думать, что это что-то в их сети. Возможно, IP-адрес меняется по запросу или что-то в этом роде. - person HitLikeAHammer; 09.07.2010