calendrier WCF par intermittence

Question

Tous,

J'ai un service WCF que les temps de manière intermittente, généralement au bout de dix ou douze demandes du client asp.net. Le service utilise la réflexion pour trouver des classes dans son assembly (DLL DLL) qui ont un ensemble d'attributs personnalisés. Le processus lui-même est très rapide, il ne prend généralement que quelques millisecondes, et quand cela fonctionne, cela fonctionne très bien.

La définition d'un point d'arrêt dans le code appelant et dans le service lui-même m'indique que le délai d'attente se produit entre l'appel de la classe de proxy client WCF et lorsque cette méthode est réellement exécutée.

Des idées?

Mise à jour: la liaison, etc de web.config:

<system.serviceModel> 
    <behaviors> 
     <serviceBehaviors> 
     <behavior name="Sdd.Services.ControlPanelBehavior"> 
      <serviceMetadata httpGetEnabled="true" /> 
      <serviceDebug includeExceptionDetailInFaults="false" /> 
     </behavior> 
     </serviceBehaviors> 
    </behaviors> 
    <services> 
     <service behaviorConfiguration="Sdd.Services.ControlPanelBehavior" 
     name="Sdd.Services.ControlPanel"> 
     <endpoint address="" binding="wsHttpBinding" contract="Sdd.Services.IControlPanel"> 
      <identity> 
      <dns value="localhost" /> 
      </identity> 
     </endpoint> 
     <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> 
     </service> 
    </services> 
    </system.serviceModel> 

MISE À JOUR: Et voici la partie pertinente de la web.config du client:

<system.serviceModel> 
    <bindings> 
    <wsHttpBinding> 
    <binding name="WSHttpBinding_IControlPanel" closeTimeout="00:01:00" 
    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" 
    bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard" 
    maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text" 
    textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false"> 
    <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" 
     maxBytesPerRead="4096" maxNameTableCharCount="16384" /> 
    <reliableSession ordered="true" inactivityTimeout="00:10:00" 
     enabled="false" /> 
    <security mode="Message"> 
     <transport clientCredentialType="Windows" proxyCredentialType="None" 
     realm="" /> 
     <message clientCredentialType="Windows" negotiateServiceCredential="true" 
     algorithmSuite="Default" establishSecurityContext="true" /> 
    </security> 
    </binding> 
    </wsHttpBinding> 
    </bindings> 
    <client> 
    <endpoint address="http://localhost:81/services/ControlPanel.svc" 
    binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IControlPanel" 
    contract="PublicSite.IControlPanel" name="WSHttpBinding_IControlPanel"> 
    <identity> 
    <dns value="localhost" /> 
    </identity> 
    </endpoint> 
    </client> 
</system.serviceModel> 

Answer 1

Oups!

Ceci est probablement la plus idiote des erreurs, mais j'ai compris le problème: comme je suis habitué à utiliser des références web (service web .asmx) au lieu de références de service (WCF), j'ai négligé objet. Changé

[WebMethod] 
    public static List<Page>PagesGetAll() 
    { 
     ControlPanelClient cp = new ControlPanelClient(); 
     Page[] pageArray = cp.NavigationPagesGetAll(); 
     List<Page> pageList = pageArray.ToList<Page>(); 

     // make sure that the page list in the database is up-to-date. 
     foreach(Page page in pageList) 
      Navigation.PageUpdate(page); 

     return pageList; 
    } 

à

public static List<Page>PagesGetAll() 
    { 
     List<Page> pageList = null; 

     using (ControlPanelClient cp = new ControlPanelClient()) 
     { 
      Page[] pageArray = cp.NavigationPagesGetAll(); 
      pageList = pageArray.ToList<Page>(); 
      // implied cp.Close() from "using" statement 
     } 

     // make sure that the page list in the database is up-to-date. 
     foreach(Page page in pageList) 
      Navigation.PageUpdate(page); 

     return pageList; 
    } 

Et le problème a disparu. Après vérification de cette solution, j'ai également augmenté le nombre de requêtes simultanées, car il semble logique qu'ayant plus de 10 à 12 requêtes simultanées crée le même problème que je voyais auparavant.

Merci à tous!

Answer 2

Une bonne façon d'aider à diagnostiquer ce type de problème est d'activer le suivi sur le client and the server et en utilisant le Service Trace View Tool. Cela vous donnera une meilleure idée de exactement où (dans quelle méthode ou appel) le problème est.

Answer 3

Malheureusement, les pièces les plus importantes de la configuration (les liaisons et les points de terminaison de service) sont manquantes - tout comme la configuration du client. Mais la façon dont vous le décrivez, que 10 à 12 demandes semblent bien fonctionner et qu'il y a un échec, pourrait indiquer un problème de concurrence/limitation sur le serveur.

Je voudrais essayer d'augmenter le nombre d'appels simultanés et de sessions juste pour voir si cela aide quelque chose. Pour ce faire, vous aurez besoin d'ajouter une section serviceThrottling à la configuration de votre comportement sur le serveur:

<behavior name="Sdd.Services.ControlPanelBehavior"> 
    <serviceMetadata httpGetEnabled="true" /> 
    <serviceDebug includeExceptionDetailInFaults="false" /> 
    <serviceThrottling 
     maxConcurrentCalls="25"   // default is 16 
     maxConcurrentSessions="25"  // default is 10 
     maxConcurrentInstances="25" /> // no default 
</behavior> 

Si cela aide - vous aviez un problème avec trop de sessions ou des appels simultanés sont ouverts. Le protocole wsHttpBinding utilisera par défaut une session, alors peut-être que vous aurez juste besoin de lui dire d'utiliser par appel à la place.

Marc