Назад | Перейти на главную страницу

asp.net с балансировщиком нагрузки

Я создал приложение проверяющей стороны на основе ASP.NET, и это приложение развернуто на сервере-ферме, где включена балансировка нагрузки и также используется липкий сеанс.

Когда запрос приходит с одного сервера в это время, он работает нормально, но во время обратной отправки, если сервер запроса изменяется в это время, он выдает исключение «Ключ недействителен для использования в указанном состоянии».

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

Я нашел в сети альтернативное решение: enableViewStateMac = "false".

Могу ли я этим воспользоваться, и в чем его недостаток?

Чтобы ответить на ваш вопрос, согласно MSDN:

Для этого атрибута никогда не следует устанавливать значение false на рабочем веб-сайте.

(Конечно, значение по умолчанию также ложно ...) Это наводит на мысль, что вы должны быть очень осторожны, делая это.

Можете ли вы включить ссылку на ресурс, который вы нашли в Интернете, который предлагал вам отключить это?

Далее, согласно блог MSDN:

Проблема в том, что если выполняется обратный POST-запрос и идет на другой сервер, вы получите небольшое приятное сообщение об ошибке «Corrupt View State».

Чтобы исправить это, вы можете либо установить для enableViewStateMac значение false в элементе, либо указать общее значение для атрибута validationKey в элементе на всех серверах (в ферме).

Это говорит мне о том, что, если сообщение об ошибке не изменилось (вполне возможно), это не то, с чем вы сталкиваетесь.

Взгляните на этот принятый ответ - https://stackoverflow.com/questions/686873/allowing-session-in-a-web-farm-is-stateserver-good-enough/687162#687162 - на Stack Overflow, чтобы убедиться, что вы правильно настроили.

В MSDN также есть статья Обзор состояния сеанса ASP.NET в котором обсуждается настройка состояния сеанса.

На данный момент я думаю, что это проблема конфигурации. Изменение machine.config должно было перезапустить пулы приложений, так что, вероятно, проблема не в этом.