Szczegółowe dochodzenie dotyczące wyjątku limitu czasu WCF

Jeśli jeszcze tego nie próbowałeś - Zamknij operacje WCF po stronie serwera w blokach try / finally i dodaj rejestr, aby upewnić się, że faktycznie powracają.

Jeśli te pokażą, że operacje są zakończone, to moim następnym krokiem będzie przejście na niższy poziom i przyjrzenie się rzeczywistej warstwie transportowej.

Wireshark lub inne podobne narzędzie do przechwytywania pakietów może być bardzo pomocne w tym momencie. Zakładam, że to działa przez HTTP na standardowym porcie 80.

Run Wireshark na kliencie. W opcjach po uruchomieniu przechwytywania ustaw filtr przechwytywania na tcp http and host service.example.com - zmniejszy to ilość nieistotnego ruchu.

Jeśli możesz, zmodyfikuj swojego klienta, aby powiadomił Cię o dokładnym czasie rozpoczęcia połączenia i czasie, w którym wystąpił limit czasu. Albo po prostu uważnie go monitoruj.

Gdy pojawi się błąd, możesz przeszukać dzienniki Wireshark, aby znaleźć początek połączenia. Kliknij prawym przyciskiem myszy na pierwszym pakiecie, który wywołuje klienta (Powinno być coś w stylu GET / service.svc lub POST / service.svc) i wybierz Follow TCP Stream.

Wireshark zdekoduje całą rozmowę HTTP, więc możesz mieć pewność, że WCF faktycznie odsyła odpowiedzi.

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

Aby uniknąć tego błędu timeout, musimy aby skonfigurować OperationTimeout właściwość dla pełnomocnika w kliencie WCF kod. Ta konfiguracja jest czymś nowe w przeciwieństwie do innych konfiguracji takich jako Send Timeout, Receive Timeout itp., które omówiłem na początku w artykuł. Aby ustawić limit czasu tej operacji konfiguracja nieruchomości, musimy wyślij naszego Pełnomocnika do IContextChannel w Aplikacja kliencka WCF przed wywołaniem metody umowy operacyjnej.

Mam bardzo podobny problem. W przeszłości było to związane z problemami serializacji. Jeśli nadal masz ten problem, czy możesz sprawdzić, czy możesz poprawnie serializować zwracane obiekty. W szczególności, jeśli używasz obiektów Linq-to-Sql, które mają relacje, znane są problemy z serializacją, jeśli umieścisz back reference na obiekcie podrzędnym do obiektu nadrzędnego i oznaczysz to back reference jako DataMember.

Możesz zweryfikować serializację przez pisanie aplikacji konsolowej, która serializuje i deserializuje obiekty za pomocą DataContractSerializer po stronie serwera i dowolnych metod serializacji używanych przez Klienta. Na przykład w naszej obecnej aplikacji mamy zarówno klientów WPF, jak i Compact Framework. Napisałem aplikację konsolową, aby sprawdzić, czy mogę serializować za pomocą DataContractSerializer i deserializować za pomocą XmlDesserializer. Możesz spróbować.

Również, jeśli zwracasz Obiekty Linq-to-Sql, które mają Kolekcje potomne, możesz spróbować upewnić się, że niecierpliwie załadowałeś je po stronie serwera. Czasami, z powodu leniwego ładowania, zwracane obiekty nie są wypełniane i mogą powodować zachowanie, które widzisz, gdy żądanie jest wysyłane do metody usługi wiele razy.

UPDATE: nie jestem pewien, czy to ci pomoże, ale Narzędzie Service Trace Viewer właśnie rozwiązało mój problem po 5 dniach bardzo podobnego doświadczenia do twojego. Konfigurując śledzenie, a następnie patrząc na raw XML, znalazłem wyjątki, które powodowały moje problemy z serializacją. Był on związany z obiektami Linq-to-SQL, które czasami miały więcej obiektów potomnych, niż można było z powodzeniem serializować. Dodawanie następujących do swojej sieci.plik konfiguracyjny powinien umożliwić śledzenie:

<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>

Wynikowy plik można otworzyć za pomocą narzędzia Service Trace Viewer lub po prostu w IE, aby zbadać wyniki.

Czy zamykasz połączenie z usługą WCF pomiędzy żądaniami? Jeśli tego nie zrobisz, zobaczysz ten dokładny limit czasu (w końcu).

Właśnie rozwiązałem problem.Znalazłem, że węzły w aplikacji.plik konfiguracyjny został źle skonfigurowany.

<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>

Potwierdź konfigurację w węźle <security>, wartość atrybutu "mode" to "None". Jeśli twoja wartość to "Transport", wystąpi błąd.

Niech pomoże Ci ten link w blogach 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

Czy próbowałeś użyć clientVia aby zobaczyć wysłaną wiadomość, używając SOAP toolkit czy coś w tym stylu? Może to pomóc sprawdzić, czy błąd pochodzi od samego klienta lub z innego miejsca.

Sprawdziłeś ślady WCF? WCF ma tendencję do połykania wyjątków i zwracania tylko ostatniego wyjątku, czyli limitu czasu, który otrzymujesz, ponieważ punkt końcowy nie zwrócił niczego znaczącego.

Zostanie również wyświetlony ten błąd, jeśli przekazujesz obiekt z powrotem do klienta, który zawiera właściwość typu enum, która nie jest domyślnie ustawiona i że enum nie ma wartości, która jest mapowana na 0. i. E enum MyEnum{ a=1, b=2};

Wygląda na to, że ten wyjątek jest dość ogólny i może być odebrany z różnych powodów. Napotkaliśmy to podczas wdrażania klienta na komputerach z systemem Windows 8.1. Nasz klient WCF działa wewnątrz usługi windows i stale bada usługę WCF. Usługa windows działa pod kontrolą Użytkownika Nie-administratora. Problem został rozwiązany przez ustawienie clientCredentialType na "Windows" w konfiguracji WCF, aby umożliwić uwierzytelnianie, jak w poniższym:

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

Nie jestem ekspertem WCF, ale zastanawiam się, czy nie napotkasz ochrony DDOS na IIS. Wiem z doświadczenia, że jeśli uruchomisz kilka jednoczesnych połączeń z jednego klienta do serwera w pewnym momencie serwer przestaje odpowiadać na połączenia, ponieważ podejrzewa atak DDOS. Będzie również utrzymywać połączenia otwarte do czasu ich wygaśnięcia, aby spowolnić klienta w jego atakach.

Wiele połączeń pochodzących z różnych maszyn / IP nie powinno być problemem jednak.

Jest więcej informacji w tym poście MSDN:

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

Zobacz sproperty MaxConcurrentSession.