Asp.net, stateserver, NLB, сессия потеряна

Не совсем ответ на ваш вопрос, но пробовали ли вы использовать хранилище сеансов на основе sql-сервера? (Ищите в MSDN постоянный сценарий, а не временный сценарий, поставляемый с asp.net)

Я слышал «плохие вещи» об исполняемой службе сеанса и, следовательно, не использовал ее. Однако никогда не было проблем с веб-фермерством с решением на основе sql-сервера.

Извините, это не совсем ответ на вашу проблему, но он должен либо (а) исправить, либо (б) значительно сузить ее.

Что ж, если вы используете Visual Studio, вы можете хотя бы протестировать ее с помощью MSDE (урезанная версия SQL Server, которая поставляется с Visual Studio) ...

Это может помочь исключить проблемы с государственным сервером ...

Использование подхода базы данных имеет свои проблемы. Я думаю, вы сможете использовать свой предпочтительный подход.

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

Или "Устранение проблем, связанных с сеансом, в ASP.NET"

Или "Устранение неполадок с истекшим состоянием сеанса ASP.NET и вашими параметрами"

Я буду хромым и повторю предложение MS SQL Server. Установите SQL Server Express, который полностью бесплатен, в том числе для коммерческого использования, и у него есть только три недостатка, которые не должны быть проблемой для вас на этом этапе:

• Максимальный размер базы данных 4 ГБ
• Используется не более 1 ядра ЦП
• Используется не более 1 ГБ ОЗУ

Несколько моментов, которые следует принять во внимание:

• Какая нагрузка на ваш сайт? Сервер состояний имеет тенденцию аварийно завершать работу при большом количестве одновременных попаданий. Мы используем его только в сценариях, где у нас действительно небольшое количество пользователей (в десятках, в основном серверные системы). Всякий раз, когда мы пытались использовать его в производственной среде для сайтов, ежедневно обслуживающих тысячи пользователей, он вылетал из строя, что приводило к потере данных сеанса.
• В одной из производственных сред, которыми мы управляем, мы используем MSSQL 2005 Express для управления сеансами, на сайте более 10 тысяч пользователей в день и более 200 тысяч страниц в день. Это рекомендуемый подход в случае, если сеанс является обязательным и тесно связан с вашим приложением.

Если вы собираетесь использовать MSSQL Express в качестве базы данных состояния, помните, что он не поставляется с агентом SQL Server, что означает, что планировщик задач не работает в фоновом режиме и не очищает истекшие сеансы. Я бы рекомендовал найти планировщик и периодически запускать чистую хранимую процедуру сеансов с истекшим сроком.

Удачи

Вместо того, чтобы возиться с SQL, отправьте свои тесты прямо в один из узлов IIS, чтобы проверить, возникает ли у вас та же проблема. Я уверен, что если вы проведете лишь небольшое количество тестов, StateServer не будет проблемой.

Попробуйте установить доменное имя asp.net_sessionid с помощью кода на ".yourdomain.com". По умолчанию для доменного имени файла cookie ASP.net_SessionID задан полный путь к приложению. Итак, это может быть одной из причин, по которой cookie не перемещается.

Например. Request.Cookies ["ASP.NET_SessionId"]. Domain = ".yourdomain.com". Помните первый "." важно в доменном имени.

Вы можете сделать это в HttpModule в событии AcquireRequestState.

Я наконец нашел ответ на свою проблему. Его происхождение находится в коде приложения (например, 99% ошибок сторонних инструментов программиста). Я все равно решил выложить его на случай, если кто-то окажется в подобном сценарии.

Этот код был частью класса WebServiceRequester. Класс инициатора запроса веб-службы был создан при создании сеанса и сохраняется в сеансе. Во время создания мы инициализируем член m_webServiceURL, и этот член сохраняется в сессии после. Значение, при котором был инициализирован этот член, зависело от настройки на локальном компьютере.

Важная часть заключается в следующем: Класс WebServiceRequester содержит объекты WebService. Объекты WebService не могут быть сохранены в сеансе, они не сериализуемы в asp. Свойство имеет атрибут [NonSerialized]. Поэтому каждый раз, когда мы обращались к свойству WebService объекта первым в течение жизненного цикла страницы, нам приходилось создавать новый и назначать ему URL-адрес m_webServiceURL, который был сохранен в сеансе. Итак, вы видите, новый объект веб-службы, возможно, на другой машине, что означает разные настройки на каждой машине.

Итак, вот что произошло: поле 29 было настроено для доступа к веб-службе на локальном хосте

поле 30 было настроено для доступа к веб-службе как 192.168.253.29.

Технически они оба установлены на одной машине. Но вот сценарий:

войдите в поле 29. m_webServiceURL установлен на localhost в сеансе.

[просьба в графе 29 здесь]

Балансировка NLB приводит нас к блоку 30. box 30 загружает сеанс, создает новый объект веб-службы с localhost в качестве адреса веб-службы. коробка 30 отправила запрос к неправильной веб-службе, что привело к исключению Session Expired.

Одна из проблем во время отладки заключалась в том, что локальные коммуникации не записывались сетевым монитором.

Что привело меня к трассировке, так это то, что у нас никогда не регистрировалось исключение в трассировке журнала ящика 29, как должно быть.

Спасибо за ваши предложения всем, это было действительно оценено.

Хорошего дня. JF