В спорадических случаях мы получаем следующую ошибку при попытке вызвать веб-службу .asmx из клиентского приложения .Net:
«Базовое соединение было закрыто: соединение, которое, как ожидалось, должно было поддерживаться, было закрыто сервером. Невозможно прочитать данные из транспортного соединения: существующее соединение было принудительно закрыто удаленным хостом».
Под спорадическим я подразумеваю, что это может происходить ноль, раз в несколько дней или полдюжины раз в день для некоторых пользователей. Это никогда не произойдет при первом обращении пользователя к веб-сервису. И последующий (обычно такой же) вызов всегда сработает сразу после сбоя. Сбои происходят с помощью различных методов в службе и обычно происходят в течение 15-20 секунд (согласно журналу) с момента запроса.
Просмотр журнала сайта IIS для конкретного вызова покажет тот или иной из следующих кодов ошибок Windows:
121: Истек срок ожидания семафора.
1236: Сетевое соединение было прервано локальной системой.
Некоторые дополнительные сведения о среде:
Работает во внутренней сети веб-фермы, состоящей из двух серверов под управлением IIS7 в ОС Windows Server 2008. Этих проблем не возникало при работе на старой веб-ферме IIS6, состоящей из трех серверов, работающих под управлением Windows Server 2003 (и мы без проблем используем один экземпляр IIS6 / 2003 для наших сред разработки и промежуточных сред). РЕДАКТИРОВАТЬ: Кроме того, все эти экземпляры серверов являются виртуальными машинами VMWare, не уверен, является ли это больше сюрпризом или нет.
Веб-служба представляет собой скомпилированную веб-службу .asmx .Net 2.0 / 3.5, которая имеет собственный пул приложений (.Net 2.0, интегрированный конвейер). Включена только проверка подлинности Windows.
У нас есть еще одна веб-служба в ферме, которая использует тот же физический путь, что и основная служба, с той лишь разницей, что включена базовая проверка подлинности. Это используется для части нашей системы ERP. Пробовали использовать один и тот же пул приложений, но это не повлияло на ошибку. Этот сайт посещается не так часто, как основной сайт, и никогда не было ошибок.
Как уже упоминалось, ошибка возникает только при вызове из клиента .Net, а не из других приложений. Клиентское приложение всегда создает новый объект веб-службы для каждого запроса и устанавливает учетные данные службы в System.Net.CredentialCache.DefaultCredentials.
Приложение либо развертывается локально на клиенте, либо запускается в сеансе сервера Citrix. Те пользователи, которые работают в Citrix, похоже, не испытывают проблемы, только локально развернутые клиенты. Серверы Citrix и веб-ферма расположены в одном физическом месте и находятся в одном диапазоне IP-адресов (10.67.xx.xx). Локально развернутые клиенты, в которых возникает ошибка, находятся в другом месте (10.105.xx.xx, 10.31.xx.xx).
Я проверил журналы ОС, чтобы увидеть, вижу ли я какие-либо проблемы, но на самом деле ничего не выделяется.
РЕДАКТИРОВАТЬ: На самом деле, я сам недавно столкнулся с ошибкой. Я решил снова проверить журналы и увидел, что в «то же самое» время в журнале безопасности была запись «Ошибка аудита» (запись журнала IIS в 1:39:59, запись в журнале событий в 1:39:50). Не уверен, совпадение это или нет, мне придется проверить журналы предыдущих ошибок. Я, наверное, цепляюсь за соломинку, но детали:
Имя журнала: Источник безопасности: Microsoft-Windows-Security-Auditing Дата: 7/8/2009 13:39:50 Идентификатор события: 5159 Категория задачи: Фильтрация Платформа Уровень подключения: Ключевые слова: Ошибка аудита Пользователь: Н / Д Компьютер: is071019. <******>. net Описание: платформа фильтрации Windows заблокировала привязку к локальному порту.
Информация о приложении: ID процесса: 1260 Имя приложения: \ device \ harddiskvolume1 \ windows \ system32 \ svchost.exe
Сетевая информация: Адрес источника: 0.0.0.0 Порт источника: 54802 Протокол: 17
Информация о фильтре: Идентификатор времени выполнения фильтра: 0 Имя слоя: Идентификатор времени выполнения уровня назначения ресурсов: 36
Я также пробовал использовать отслеживание неудачных запросов в IIS7, но вызов службы никогда не попадает туда, где FRT может его захватить (даже если сбой регистрируется в журнале веб-службы).
Группа сетевой инфраструктуры заявила, что они проверили DNS, и все настройки сетевого адаптера верны, поэтому нет никакого «колебания». Все получается. Я не уверен, что они проверяли какие-либо серверы контроллеров домена, чтобы узнать, может ли это быть проблемой.
Любые идеи? Или любые другие стратегии отладки, чтобы разобраться в этом? Я просто разработчик, отвечающий за программное обеспечение, и на самом деле не знаю, что исследовать с сетевой стороны - хотя для меня это действительно похоже на сетевую проблему, исходя из того, что происходит.
Заранее благодарю за любую помощь.
Вам необходимо включить платформу фильтрации Windows? Если вам разрешено отключить его, это должно избежать этой ошибки аудита; если вы должны включить его, возможно, они могут сделать исключение, чтобы вы могли отключить категорию аудита - см.: http://msdn.microsoft.com/en-us/library/bb309058(VS.85).aspx
Если вам необходимо оставить WFP включенным и неповрежденным, это не поможет.
Вы можете создать страницу, которая выйдет из строя с ошибкой, когда это произойдет (попробуйте catch), а затем использовать WCAT для имитации различных условий загрузки. Надеюсь, тогда вы сможете увидеть закономерность или, по крайней мере, увидеть, связана ли она с нагрузкой. В противном случае я бы просто встроил что-то в клиент .Net, которое улавливает эту проблему и просто повторяет запрос, чтобы он был прозрачным для пользователя.
Я также сталкиваюсь с такой же спорадической ситуацией только в производственной среде. Некоторые из предложений, которые я нашел, но еще не проверил, - это либо отключить Http Keep-Alive на сервере, либо отключить его при веб-запросе. Видеть http://support.microsoft.com/kb/819450
Я планирую протестировать это в тестовой среде.