Сбой службы WCF в Windows Server 2003 / IIS6 - базовое соединение было закрыто

Question

У меня проблема с сервисом WCF. Он выполняет привязку WebHTTP и является службой, которая получает изображения.

Проблема в том, что с некоторыми изображениями сервер не может получить входящий поток. Проблема не в размере. Он может принимать файлы размером 100 КБ и 4 МБ, но не может получать файлы размером 800 КБ. «Дефектное» изображение никогда не будет успешным, а «хорошее» изображение всегда будет успешным.

Мой текущий подозреваемый - IIS 6. Он работает как в тестовом, так и в производственном режиме на IIS 7 и IIS 7.5, но на этом клиентском сайте с IIS 6 происходит сбой.

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

Ниже приведены неприятные подробности, как я вижу соответствующие.

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

Машина

Windows 2003 R2, SP2 + IIS 6, + .Net 2.0 + 3.5

WCF

Я изменил Transfermode на Buffered для моей службы WCF, и после этого код службы даже не вызывается. Так что я не подозреваю настройки WCF.

Я включил meesageLogging для WCF, который снова почти ничего мне не дает.

<system.serviceModel>
    <diagnostics>
    <messageLogging logEntireMessage="true" logMalformedMessages="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true" maxMessagesToLog="-1"/>
    </diagnostics>

Регистрация в файле журнала впоследствии дает мне следующее:

Основная информация:

Название операции: Обработка сообщения 1.

Время: 2012-03-22 09: 27: 56.1996

Уровень: Ошибка

Источник: System.ServiceModel

Процесс: w3wp

Тема: 12

Сообщение об исключении:

Количество доступных байтов не согласуется с заголовком HTTP Content-Length. Возможно, произошла ошибка сети или клиент отправляет недействительные запросы.

Исключение Stakctrace:

System.ServiceModel.Channels.HttpInput.ReadBufferedMessage (Stream InputStream) System.ServiceModel.Channels.HttpInput.ParseIncomingMessage (Исключение & requestException) System.ServiceModel.Channels.HttpRequestContext.CreateMessage () System.ServiceModel.Channels.HttpChannelListener.HttpContextReceived (HttpRequestContext контекст, обратный вызов ItemDequeuedCallback) System.ServiceModel.Activation.HostedHttpTransportManager.HttpContextReceived (HostedHttpRequestAsyncResult результат) System.ServiceModel.Activation.HostedHttpRequestAsyncResult.HandleRequest () System.ServiceModel.Activation.HostedHttpRequestAsyncResult.BeginRequest () System.ServiceModel.Activation.HostedHttpRequestAsyncResult.OnBeginRequest (Объект государство) System.ServiceModel.PartialTrustHelpers.PartialTrustInvoke (ContextCallback обратный вызов, состояние объекта) System.ServiceModel.Activation.HostedHttpRequestAsyncResult.OnBeginRequestWithFlow (Объект государство) System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.WorkItem.Invoke2 () System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.WorkItem.Invoke () System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.ProcessCallbacks () System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.CompletionCallback (Объект государство) System.ServiceModel.Channels.IOThreadScheduler.CriticalHelper.ScheduledOverlapped.IOCallback (UInt32 errorCode, UInt32 numBytes, NativeOverlapped * nativeOverlapped) System.ServiceModel.Diagnostics.Utility.IOCompletionThunk.UnhandledExceptionFrame (UInt32 ошибка, UInt32 bytesRead, NativeOverlapped * nativeOverlapped) System.Threading._IOCompletionCallback.PerformIOCompletionCallback (UInt32 errorCode, UInt32 numBytes, NativeOverlapped * pOVERLAP)

Опять же, доказательство того, что не наша служба WCF ответственна за ошибку, а где-то в конвейере WCF.

HTTPERR

Я проверил журналы HTTPERR IIS и ничего там, кроме записей Timer_ConnectionIdle, которые не должны иметь значения.

Fiddler

Fiddler просто заявляет очевидное:

[Fiddler] ReadResponse () не удалось: сервер не вернул ответ на этот запрос.

Если понадобится дополнительная информация, дайте мне знать, и я отправлю ее.

С наилучшими пожеланиями / Андерс

Answer 1

Так что у меня тоже была эта проблема. Сначала я подумал, что это может быть проблема с потоками (хотя это было против моего лучшего суждения). Я сделал свои сервисные вызовы потокобезопасными, а затем перешел к реальному исключению после того, как преодолел крах рабочего процесса. Для меня проблема заключалась в том, что я писал и читал из общего ресурса с указанными учетными данными, используя олицетворение. Тем не менее, доля не смогла получить больше соединений. Даже несмотря на то, что я выходил из системы (закрывая ручку), очевидно, связи все еще оставались. В итоге я использовал MemoryCache, чтобы немного дольше хранить токены и повторно использовать их, когда общий ресурс и пользователь были одинаковыми для любого конкретного элемента мультимедиа в моей базе данных.

Я не уверен, что у вас та же проблема, но у нас были одинаковые симптомы. Мой сервис WCF читает и пишет в общий ресурс. Используя класс SafeThread (я изменил код из исходного кода: http://www.codeproject.com/KB/threads/SafeThread.aspx) Я смог предотвратить сбой рабочего процесса и увидеть, как моя настоящая ошибка записывается в журнал.

Статья базы знаний. http://support.microsoft.com/kb/179483

Надеюсь, это кому-нибудь поможет.