Не удалось загрузить viewstate на NLB

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

Проблема в том, что на рабочем сервере (2 узла на NLB) мы случайно получаем в разных точках сети без корреляции, которую мы обнаружили, не удалось загрузить состояние представления, дерево управления может иметь другую ошибку. Однако точно такого же кода на нашем промежуточном сервере (такая же настройка NLB, как и на производстве) такого никогда не было.

Я в основном исключаю, что его код на данный момент, так как это вообще не происходит в dev / staging или локальной среде, где на производстве это довольно часто. Это приводит меня к убеждению, что где-то произошла ошибка конфигурации.

Я установил жестко закодированные машинные ключи в web.config, который используется при подготовке и производстве, а сеансы поддерживаются на MSSQL.

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

Наш webconfig находится здесь на pastbin: http://pastebin.com/m2kRTd0k

Источник

3 ответа

Вот несколько вещей, которые вы можете проверить:

  • Вы уверены, что отредактированные вами файлы web.config используются? Попробуйте добавить в них синтаксическую ошибку и убедитесь, что вы получили ошибку.
  • Убедитесь, что Sticky IP не настроен в вашей рабочей среде
  • Убедитесь, что ваши среды находятся на одном уровне исправлений, возможно, одно из них имеет значение по умолчанию, отличное от другого.
  • Также может быть разница в сетевой инфраструктуре, где расположены 2 среды
Источник

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

Поскольку существует так много типов вопросов (например, да / нет, на основе значений, множественный выбор, ползунки, многоуровневые раскрывающиеся списки и т. Д.), Мы должны динамически создавать форму.

Мы столкнемся с проблемами на производстве, но не с нашей средой разработки или тестирования, похожей на вас самих; но нашей проблемой был код. Когда мы запустили приложение в производство, было гораздо больше пользователей, работающих по гораздо большему количеству сценариев, чем мы когда-либо могли в dev/qa.

Всякий раз, когда мы видим "не удалось загрузить viewstate", выполнение одной из этих двух вещей обычно решает проблему:

  • Создавайте все элементы управления динамически только на этапе INIT. Это должно быть сделано здесь для правильной работы ViewState без особых дополнительных размышлений. ViewState загружается после завершения INIT и сохраняет после завершения PRERENDER. Мы можем создать элементы управления уже на этапе ЗАГРУЗКИ, но в проводке могут быть нюансы. (Http://msdn.microsoft.com/en-us/library/ms178472.aspx#general_page_lifecycle_stages)

  • Выключите AJAX и посмотрите, исправит ли это (обычно это виновник). Если это исправит это, то мы просто должны проверить, что нет никаких постов AJAX, которые заставляют страницу менять свой макет. Вызов AJAX может сделать что-то столь же простое, как сделать элемент управления невидимым, или повторно отобразить элемент управления с новым идентификатором, в результате чего следующая следующая нормальная обратная передача обнаружит изменения в дереве элементов управления. Если нам нужно сделать элементы управления невидимыми через ajax, мы просто добавим атрибут ('display','none'). После того, как мы закончим с изменениями, мы снова включаем AJAX.

Источник

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

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

Источник

Это происходит для разных браузеров? Существуют более старые версии Safari и некоторые прокси-серверы, которые усекают ViewState при передаче его обратно на сервер.

Одна вещь, которую вы, возможно, захотите попробовать Chunking viewstate. Вы можете сделать это, установив maxPageStateFieldLength атрибут на pages тег в вашем web.config. Вот пример

<pages maxPageStateFieldLength="900">

Наконец, вы можете рассмотреть возможность вообще не использовать viewState clientSide. Вот статья, в которой реализован серверный поставщик представления состояния на основе SQL: http://www.codeproject.com/KB/viewstate/ViewStateProvider.aspx

Источник
Другие вопросы по тегам