В WCF исключение timeout детальное расследование

Если вы еще не пробовали-инкапсулируйте свои серверные операции WCF в блоках try/finally и добавьте ведение журнала, чтобы убедиться, что они действительно возвращаются.

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

Wireshark или другой подобный инструмент захвата пакетов может быть весьма полезным на данном этапе. Я предполагаю, что это работает через HTTP на стандартном порту 80.

запустите Wireshark на клиенте. В параметрах при запуске захвата установите фильтр захвата в tcp http and host service.example.com - Это уменьшит количество нерелевантного трафика.

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

когда вы получаете ошибку, то вы можете тралить через журналы Wireshark, чтобы найти начало вызова. Щелкните правой кнопкой мыши на первый пакет ваш клиент звонит на него (должно быть что-то вроде GET /service.svc или POST / service.svc) и выберите следовать потоку TCP.

Wireshark будет декодировать весь HTTP-разговор, поэтому вы можете убедиться, что WCF фактически отправляет ответы.

from:http://www.codeproject.com/KB/WCF/WCF_Operation_Timeout_.aspx

чтобы избежать этой ошибки тайм-аута, нам нужно к настройка OperationTimeout свойство для прокси-сервера в клиенте WCF код. Эта конфигурация что-то новые в отличие от других конфигураций, таких как как отправить тайм-аут, тайм-аут получения и т. д., который я обсуждал в начале статья. Чтобы установить тайм-аут этой операции конфигурация свойства, мы должны cast наш прокси в IContextChannel в Клиентское приложение WCF перед вызовом методы контракта операции.

У меня очень похожая проблема. В прошлом, это было связано с проблемами сериализации. Если у вас все еще есть эта проблема, вы можете проверить, что можете правильно сериализовать возвращаемые объекты. В частности, если вы используете объекты Linq-to-Sql, которые имеют отношения, существуют известные проблемы сериализации, если вы помещаете обратную ссылку на дочерний объект в родительский объект и помечаете эту обратную ссылку как элемент данных.

вы можете проверить сериализация путем написания консольного приложения, которое сериализует и десериализует объекты с помощью DataContractSerializer на стороне сервера и любых методов сериализации, используемых клиентом. Например, в нашем текущем приложении у нас есть клиенты WPF и Compact Framework. Я написал консольное приложение, чтобы убедиться, что я могу сериализовать с помощью DataContractSerializer и десериализовать с помощью XmlDesserializer. Можешь попробовать.

кроме того, если вы возвращаете объекты Linq-to-Sql, которые у вас есть дочерние коллекции, вы можете попытаться убедиться, что вы охотно загрузили их на стороне сервера. Иногда из-за ленивой загрузки возвращаемые объекты не заполняются и могут вызвать поведение, которое вы видите, когда запрос отправляется методу службы несколько раз.

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

обновление: я не конечно, если это поможет вам, но сервис Trace Viewer Tool только что решил мою проблему после 5 дней очень похожего опыта на ваш. Настроив трассировку, а затем посмотрев на необработанный XML, я нашел исключения, которые вызывали проблемы сериализации. Он был связан с объектами Linq-to-SQL, которые иногда имели больше дочерних объектов, чем могли быть успешно сериализованы. Добавление следующего в ваш интернет.файл конфигурации должен включать трассировку:

<sharedListeners>
    <add name="sharedListener"
         type="System.Diagnostics.XmlWriterTraceListener"
         initializeData="c:\Temp\servicetrace.svclog" />
  </sharedListeners>
  <sources>
    <source name="System.ServiceModel" switchValue="Verbose, ActivityTracing" >
      <listeners>
        <add name="sharedListener" />
      </listeners>
    </source>
    <source name="System.ServiceModel.MessageLogging" switchValue="Verbose">
      <listeners>
        <add name="sharedListener" />
      </listeners>
    </source>
  </sources>

результирующий файл может быть открыт с помощью инструмента Service Trace Viewer или просто в IE для изучения результатов.

вы закрываете соединение со службой WCF между запросами? Если вы этого не сделаете, вы увидите этот точный тайм-аут (в конце концов).

Я только что решил проблему.Я обнаружил, что узлы в приложении.файл конфига есть configed неправильно.

<client>
<endpoint name="WCF_QtrwiseSalesService" binding="wsHttpBinding" bindingConfiguration="ws" address="http://cntgbs1131:9005/MyService/TGE.ISupplierClientManager" contract="*">
</endpoint>
</client>

<bindings>
    <wsHttpBinding>
        <binding name="ws" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" messageEncoding="Text">
            <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
            <**security mode="None">**
                <transport clientCredentialType="None"></transport>
            </security>
        </binding>
    </wsHttpBinding>
</bindings>

подтвердите свою конфигурацию в узле <security>, значение атрибута "mode" - "None". Если значение равно "транспорт",возникает ошибка.

может это поможет вам эту ссылку в блогах Msdn:

http://blogs.msdn.com/tess/archive/2009/01/09/net-hang-my-application-hangs-after-i-called-my-wcf-service-a-couple-of-times.aspx

вы пытались использовать clientVia чтобы увидеть отправленное сообщение, используйте SOAP toolkit или что-то подобное? Это может помочь увидеть, поступает ли ошибка от самого клиента или откуда-то еще.

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

вы также получите эту ошибку, если передаете объект обратно клиенту, который содержит свойство типа enum, которое не задано по умолчанию, и это перечисление не имеет значения, которое сопоставляется с 0. я.е enum MyEnum{ a=1, b=2};

похоже, что это сообщение об исключении является довольно общим и может быть получено по разным причинам. Мы столкнулись с этим при развертывании клиента на машинах Windows 8.1. Наш клиент WCF работает внутри службы windows и постоянно опрашивает службу WCF. Служба windows работает под управлением пользователя, не являющегося администратором. Проблема была устранена путем установки clientCredentialType в" Windows " в конфигурации WCF, чтобы разрешить проверку подлинности для прохождения, как в следующем:

      <security mode="None">
        <transport clientCredentialType="Windows" proxyCredentialType="None"
          realm="" />
        <message clientCredentialType="UserName" algorithmSuite="Default" />
      </security>

Я не эксперт WCF, но мне интересно, не сталкиваетесь ли вы с защитой DDOS на IIS. Я знаю по опыту, что если вы запускаете кучу одновременных подключений от одного клиента к серверу в какой-то момент сервер перестает отвечать на вызовы, поскольку он подозревает DDOS-атаку. Он также будет держать соединения открытыми, пока они тайм-аут, чтобы замедлить клиента в его атаках.

множественное соединение, поступающее с разных машин / IP, не должно быть проблема, однако.

в этом сообщении MSDN есть дополнительная информация:

http://msdn.microsoft.com/en-us/library/bb463275.aspx

Проверьте MaxConcurrentSession sproperty.