Зависание клиента WCF при прерывании обслуживания

Question

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

Служба работает с BasicHttpBinding и размещается на IIS6 (страница .svc) с использованием transferMode="Streamed" и messageEncoding="Mtom". Служба настроена на использование InstanceContextMode по умолчанию (я думаю, это Per Call?) И ConcurrencyMode = Single. Он использует поведение регулирования по умолчанию, но я нахожусь в изолированной тестовой среде, в которую больше никто не попадает.

Клиентами являются Windows Services. Я использую ServiceProxyHelper , чтобы убедиться, что соединения Close() 'd или Abort()' будут правильно, когда Dispose() 'd, хотя сеансов нет, поэтому я не думаю, что это даже имеет значение При возникновении ошибки объект Client удаляется, а затем выходит из области видимости. После обнаружения исключения служба немного ждет, затем создает новый клиентский объект и пытается снова. Поэтому он должен восстановиться после сбоя, но по какой-то причине все последующие вызовы службы завершатся неудачно.

Я могу надежно воспроизвести это, запустив клиент, позволив ему передать несколько файлов, а затем сбросив настройки сервера. Сначала клиент обычно отображает ошибку «Служба слишком занята» (которая соответствует ошибке IIS 503, возникающей при перезапуске приложения). После этого все последующие звонки в сервис истекают. Насколько я могу судить, звонки даже не предпринимаются клиентом. У меня включена трассировка, и я вижу следующее: ошибка тайм-аута, за которой следует предупреждение «Не удалось отправить сообщение запроса по HTTP», а затем еще одна ошибка тайм-аута.

Сумасшедшая вещь в том, что когда я настраиваю клиент для использования Fiddler (порт 8888) в качестве прокси в app.config, все работает как нужно. Так что каким-то образом Fiddler в качестве прокси-сервера закрывает или завершает какое-то соединение, которое не является WCF.

Мысли

Редактировать 2009-10-30 8:54 PM: атрибуты службы изменены на: InstanceContextMode = Single и ConcurrencyMode = Multiple. Без разницы.

Answer 1

Ну, это было больно. Это заняло у меня целую вечность, но в конце концов я сосредоточился на разнице между запуском с прокси и без и начал изучать настройки <system.net>. Оказывается, что добавление этого бита конфигурации к клиенту решает проблему:

  <system.net>
    <settings>
      <servicePointManager expect100Continue="false" />
    </settings>
  </system.net>

Может кто-нибудь объяснить, что происходит? Почему этот параметр должен вызывать непоправимый зависание клиентов WCF при прерывании работы службы?

Answer 2

Вы уверены, что это не проблема на стороне клиента? Если ваша служба Windows выполняет вызовы WCF в отдельном потоке из основного, и у вас есть необработанное исключение, происходящее в дочернем потоке ... вызывающий поток может сидеть или не сидеть и ждать навсегда потому что он ждет возврата этой нити.

Это объяснило бы, почему внутри службы есть Исключение, а затем похоже, что служба больше не обращается к службе ... она зависла.

Раньше была огромная проблема при использовании таймеров для порождения процессов в .NET 2.0 Windows Services.