Какой 130-секундный тайм-аут убивает мой вызов службы потоковой передачи WCF? - программирование
Подтвердить что ты не робот

Какой 130-секундный тайм-аут убивает мой вызов службы потоковой передачи WCF?

Совсем недавно я начал исследовать сложную проблему с потоковой передачей WCF, в которой создается CommunicationException, если клиент ждет более 130 секунд между отправками на сервер.

Вот полное исключение:

System.ServiceModel.CommunicationException was unhandled by user code
  HResult=-2146233087
  Message=The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '23:59:59.9110000'.
  Source=mscorlib
  StackTrace:
    Server stack trace: 
       at System.ServiceModel.Channels.HttpOutput.WebRequestHttpOutput.WebRequestOutputStream.Write(Byte[] buffer, Int32 offset, Int32 count)
       at System.IO.BufferedStream.Write(Byte[] array, Int32 offset, Int32 count)
       at System.Xml.XmlStreamNodeWriter.FlushBuffer()
       at System.Xml.XmlStreamNodeWriter.GetBuffer(Int32 count, Int32& offset)
       at System.Xml.XmlUTF8NodeWriter.InternalWriteBase64Text(Byte[] buffer, Int32 offset, Int32 count)
       at System.Xml.XmlBaseWriter.WriteBase64(Byte[] buffer, Int32 offset, Int32 count)
       at System.Xml.XmlDictionaryWriter.WriteValue(IStreamProvider value)
       at System.ServiceModel.Dispatcher.StreamFormatter.Serialize(XmlDictionaryWriter writer, Object[] parameters, Object returnValue)
       at System.ServiceModel.Dispatcher.OperationFormatter.OperationFormatterMessage.OperationFormatterBodyWriter.OnWriteBodyContents(XmlDictionaryWriter writer)
       at System.ServiceModel.Channels.Message.OnWriteMessage(XmlDictionaryWriter writer)
       at System.ServiceModel.Channels.TextMessageEncoderFactory.TextMessageEncoder.WriteMessage(Message message, Stream stream)
       at System.ServiceModel.Channels.HttpOutput.WriteStreamedMessage(TimeSpan timeout)
       at System.ServiceModel.Channels.HttpOutput.Send(TimeSpan timeout)
       at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.SendRequest(Message message, TimeSpan timeout)
       at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
       at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
    Exception rethrown at [0]: 
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
       at WcfService.IStreamingService.SendStream(MyStreamUpRequest request)
       at Client.Program.<Main>b__0() in c:\Users\jpierson\Documents\Visual Studio 2012\Projects\WcfStreamingTest\Client\Program.cs:line 44
       at System.Threading.Tasks.Task.Execute()
  InnerException: System.IO.IOException
       HResult=-2146232800
       Message=Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host.
       Source=System
       StackTrace:
            at System.Net.Sockets.NetworkStream.MultipleWrite(BufferOffsetSize[] buffers)
            at System.Net.ConnectStream.InternalWrite(Boolean async, Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
            at System.Net.ConnectStream.Write(Byte[] buffer, Int32 offset, Int32 size)
            at System.ServiceModel.Channels.BytesReadPositionStream.Write(Byte[] buffer, Int32 offset, Int32 count)
            at System.ServiceModel.Channels.HttpOutput.WebRequestHttpOutput.WebRequestOutputStream.Write(Byte[] buffer, Int32 offset, Int32 count)
       InnerException: System.Net.Sockets.SocketException
            HResult=-2147467259
            Message=An existing connection was forcibly closed by the remote host
            Source=System
            ErrorCode=10054
            NativeErrorCode=10054
            StackTrace:
                 at System.Net.Sockets.Socket.MultipleSend(BufferOffsetSize[] buffers, SocketFlags socketFlags)
                 at System.Net.Sockets.NetworkStream.MultipleWrite(BufferOffsetSize[] buffers)
            InnerException:

Похоже, что сервер закрыл соединение преждевременно из-за неактивности соединения. Если я вместо этого передаю импульс серверу, даже по одному байту за раз, то я никогда не получу этого исключения, и я могу продолжать передавать данные на неопределенный срок. Я разработал очень простое примерное приложение для демонстрации этого, которое использует basicHttpBinding с Streamed transferMode, и я вставляю искусственную задержку в рамках реализации пользовательского потока на клиенте, которая задерживается на 130 секунд. Это имитирует что-то похожее на условие ожидания под буфером, в котором поток, предоставленный в моем сервисном вызове от клиента, не доставляет данные в инфраструктуру WCF достаточно быстро, чтобы удовлетворить какое-то неидентифицируемое значение таймаута, которое составляет около 130 секунд знак.

Используя инструменты трассировки службы WCF, я могу найти HttpException с сообщением, которое гласит: "Клиент отключен, потому что базовый запрос завершен. Больше недоступен доступ к HttpContext."

Из файла журнала трассировки IIS Express я вижу запись, в которой говорится: "Операция ввода-вывода была прервана из-за выхода потока или запроса приложения (0x800703e3)"

Я настроил тайм-ауты сервера и клиента, чтобы использовать значение над отметкой 130 секунд только для того, чтобы исключить их. Я пробовал idleTimeout в IIS Express и множество значений тайм-аута, связанных с ASP.NET, чтобы узнать, откуда эта проблема, но до сих пор не повезло. Самая лучшая информация, которую я могу найти до сих пор, - это комментарий в отслеживателе проблем FireFox разработчиком, который описывает аналогичную проблему, работающую вне архитектуры WCF. По этой причине я предполагаю, что проблема может быть связана скорее с IIS7 или, возможно, с Windows Server.

Пользовательская привязка на сервере Web.config

<binding name="myHttpBindingConfiguration"
         closeTimeout="02:00:00"
         openTimeout="02:00:00"
         receiveTimeout="02:00:00"
         sendTimeout="02:00:00">
  <textMessageEncoding messageVersion="Soap11" />
  <httpTransport maxBufferSize="65536"                        
                 maxReceivedMessageSize="2147483647"
                 maxBufferPoolSize="2147483647"
                 transferMode="Streamed" />
</binding>

Конфигурация клиентской стороны в коде:

    var binding = new BasicHttpBinding();
    binding.MaxReceivedMessageSize = _maxReceivedMessageSize;
    binding.MaxBufferSize = 65536;
    binding.ReaderQuotas.MaxStringContentLength = int.MaxValue;
    binding.ReaderQuotas.MaxArrayLength = int.MaxValue;
    binding.TransferMode = TransferMode.Streamed;
    binding.ReceiveTimeout = TimeSpan.FromDays(1);
    binding.OpenTimeout = TimeSpan.FromDays(1);
    binding.SendTimeout = TimeSpan.FromDays(1);
    binding.CloseTimeout = TimeSpan.FromDays(1);

В ответ на идею wals попытаться выяснить, получаю ли я разные результаты, самостоятельно разместив свою службу, я хочу добавить, что я это сделал, и обнаружил, что получаю те же результаты, что и при размещении в IIS. Что это значит? Я предполагаю, что это означает, что проблема связана либо с WCF, либо с базовой сетевой инфраструктурой в Windows. Я использую 64-разрядную версию Windows 7, и мы обнаружили эту проблему, запустив различные клиенты и выполнив часть службы на сервере Windows 2008 Server.

Обновление 2013-01-15

Я нашел некоторые новые подсказки благодаря DarkWanderer, когда понял, что WCF использует HTTP.sys под сценариями самообслуживания в Windows 7. Это заставило меня посмотреть, что я могу настроить для HTTP.sys, а также какие проблемы люди сообщают, что для HTTP.sys это похоже на то, что я испытываю. Это приведет меня к файлу журнала, расположенному в каталоге C:\Windows\System32\LogFiles\HTTPERR\httperr1.log, который, как представляется, регистрирует определенные типы HTTP-проблем со стороны HTTP.sys. В этом журнале я вижу следующий тип записи журнала каждый раз, когда я запускаю свой тест.

2013-01-15 17:17:12 127.0.0.1 59111 127.0.0.1 52733 HTTP/1.1 POST /StreamingService.svc - - Timer_EntityBody -

Итак, чтобы определить, какие условия могут привести к ошибке Timer_EntityBody, и какие настройки в IIS7 или где-либо еще могут иметь отношение к тому, когда и если эта ошибка возникает.

Из официального веб-сайта IIS:

Соединение истекло до того, как появился объект сущности запроса. Когда это ясно, что запрос имеет тело сущности, HTTP API включает Таймер Timer_EntityBody. Первоначально предел этого таймера установлен на значение connectionTimeout. Каждый раз, когда отображается другая информация полученный по этому запросу, HTTP API сбрасывает таймер, чтобы дать соединение больше минут, как указано в connectionTimeout атрибут.

Попытка изменить атрибут connectionTimeout в качестве ссылки выше предполагает, что в applicationhost.config для IIS Express, похоже, не имеет никакого значения. Возможно, IIS Express игнорирует эту конфигурацию и использует внутреннее жесткое кодированное значение? Попробовав что-то самостоятельно, я обнаружил, что добавлены новые команды http: netsh, чтобы показать и добавить значения тайм-аута, поэтому, чтобы я пошел, я придумал следующую команду, но, к сожалению, это не повлияло и на эту ошибку.

netsh http add timeout timeouttype = IdleConnectionTimeout value = 300

4b9b3361

ОТВЕТЫ

Ответ 1

Оказывается, эта проблема вызвана значением Время ожидания подключения, которое используется HTTP.sys, и которое может быть указано через диспетчер IIS через Дополнительные настройки для отдельного сайта. Это значение настроено по умолчанию для отключения соединения, когда и заголовок и тело не были получены в течение 120 секунд. Если получен импульс данных из тела, тогда сервер перезапускает таймер (Timer_EntityBody) в пределах значения тайм-аута, тогда таймер reset ожидает дополнительных данных.

Connection Time-out setting in IIS

Это как документация в отношении Timer_EntityBody и connectionTimeout, но это было трудно определить, потому что кажется, что IIS Express игнорирует значение connectionTimeout, указанное в элементе ограничений в applicationhost.config независимо от того, что говорит документация. Чтобы определить это, мне пришлось установить полную версию IIS на мою машину разработки и изменить настройку выше после размещения моего сайта там.

Поскольку мы размещаем реальный сервис в IIS в Windows 2008, вышеупомянутое решение будет работать для меня, однако остается открытым вопрос о том, как правильно изменить значение времени ожидания соединения в тех случаях, когда вы являетесь Self Hosting.

Ответ 2

Судя по ошибке:

Соединение сокетов было прервано. Это может быть вызвано ошибкой обработка вашего сообщения или превышение тайм-аута приема удаленный хост или проблема с сетевым ресурсом. Локальный разъем таймаут был "23: 59: 59.9110000"

Похоже, это простой тайм-аут TCP.

Вы можете проверить это, запустив приложение как самостоятельное размещение, а затем выполнив эту команду в консоли:

netstat -no |find "xxxxx"

где xxxxx - это PID вашего серверного процесса. Эта команда покажет вам соединения, которые ваш сервер установил и обновил каждую секунду.

Попробуйте подключиться к клиенту и посмотреть, что произойдет. Скорее всего, вы увидите "CLOSE_WAIT" или "TIME_WAIT" на вашем соединении примерно через 100-120 секунд - это будет означать, что он был прерван из-за таймаута.

Это может быть исправлено, добавив в конфигурацию следующее:

<httpTransport maxBufferSize="65536"                        
             maxReceivedMessageSize="2147483647"
             maxBufferPoolSize="2147483647"
             transferMode="Streamed"
             keepAliveEnabled="true" /> <!-- Here -->

Этот параметр объясняется здесь

Ответ 3

Вероятно, длинный снимок, но... Проверьте свой пул приложений IIS, если он включен. Он в расширенных настройках, группировка модели процесса.

Ответ 4

Попробуйте это, для меня это решило проблему. Проблема в том, что базовое ядро ​​http.sys имеет свой тайм-аут, и оно нарушит соединение.

http://mmmreddy.wordpress.com/2013/07/11/wcf-use-of-http-transport-sharing-persistent-tcp-sessions/

netsh http add timeout timeouttype=idleconnectiontimeout value=120

Ответ 5

Вы считали http://support.microsoft.com/kb/946086?

Я наблюдал такие потоковые прерывания в моих ISAPI-расширениях. После выключения буферизация в IIS 7 в соответствии с этим примечанием к суппорту, когда-либо работало оштрафованным.