Enquête détaillée sur l'exception relative au délai d'attente de la WCF

si vous ne l'avez pas déjà essayé - encapsulez vos opérations WCF côté serveur dans les blocs try/finally, et ajoutez la journalisation pour vous assurer qu'elles reviennent réellement.

si ceux-ci montrent que les opérations sont terminées, alors ma prochaine étape serait d'aller à un niveau inférieur, et de regarder la couche de transport réelle.

Wireshark ou un autre outil similaire de capture de paquets peut être très utile à ce stade. Je suppose que cela fonctionne sur HTTP sur le port standard 80.

Lancez Wireshark sur le client. Dans les Options lorsque vous démarrez la capture, définissez le filtre de capture à tcp http and host service.example.com - cela réduira la quantité de trafic non pertinent.

si vous le pouvez, modifiez votre client pour vous informer de l'heure exacte du début de l'appel, et de l'heure à laquelle le délai s'est produit. Ou tout simplement de le surveiller de près.

quand vous obtenez une erreur, alors vous pouvez trawl à travers les logs Wireshark pour trouver le début de l'appel. Cliquez avec le bouton droit de la souris sur le premier paquet sur lequel votre client appelle (cela devrait être quelque chose comme GET /service).svc ou Poste /service.svc) et sélectionnez Suivre TCP Stream.

Wireshark décodera toute la Conversation HTTP, de sorte que vous pouvez vous assurer que WCF envoie effectivement des réponses.

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

pour éviter cette erreur de temporisation, nous avons besoin à configurer le OperationTimeout propriété pour mandataire dans le client WCF code. Cette configuration est quelque chose nouveau contrairement à d'autres configurations telles comme envoyer Timeout, recevoir Timeout etc., dont j'ai parlé au début du article. Pour régler cette opération temps mort propriété configuration, nous devons lancer notre mandataire à IContextChannel dans Application client WCF avant d'appeler le contrat d'opération méthodes.

j'ai un problème similaire. Dans le passé, cela a été lié à des problèmes de sérialisation. Si vous rencontrez toujours ce problème, pouvez-vous vérifier que vous pouvez correctement sérialiser les objets sont de retour. Plus précisément, si vous utilisez des objets Linq-to-Sql qui ont des relations, il y a des problèmes connus de sérialisation si vous mettez une référence back sur un objet enfant à l'objet parent et marquez cette référence back comme un DataMember.

vous pouvez vérifiez la sérialisation en écrivant une application de console qui sérialise et désérialise vos objets en utilisant le DataContractSerializer du côté du serveur et quelles que soient les méthodes de sérialisation utilisées par votre client. Par exemple, dans notre application actuelle, nous avons à la fois des clients WPF et Compact Framework. J'ai écrit une application de console pour vérifier que je peux sérialiser en utilisant un DataContractSerializer et deserialiser en utilisant un XmlDesserializer. Vous pourriez essayer ça.

aussi, si vous revenez Linq-to-Sql objets qui ont des collections d'enfants, vous pourriez essayer de s'assurer que vous avez chargé avidement du côté du serveur. Parfois, à cause du chargement paresseux, les objets retournés ne sont pas remplis et peuvent causer le comportement que vous voyez où la requête est envoyée à la méthode de service plusieurs fois.

si vous avez résolu ce problème, j'aimerais entendre comment parce que je suis coincé avec elle aussi. J'ai vérifié que mon problème n'est pas la sérialisation donc je suis à une perte.

mise à jour: Je ne suis pas sûr que cela vous aidera, mais L'outil de suivi de trace de Service vient de résoudre mon problème après 5 jours d'expérience très similaire à la vôtre. En établissant le traçage et en regardant ensuite le XML brut, j'ai trouvé les exceptions qui causaient mes problèmes de sérialisation. Il s'agissait d'objets Linq-to-SQL qui, à l'occasion, avaient plus d'objets enfants que ceux qui pouvaient être sérialisés avec succès. Ajouter ce qui suit à votre site web.fichier de configuration devrait permettre le suivi:

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

le fichier résultant peut être ouvert avec le Service Trace Viewer Tool ou tout simplement dans IE pour examiner les résultats.

est-ce que vous fermez la connexion au service WCF entre les demandes? Si vous ne le faites pas, vous verrez cette heure exacte (éventuellement).

je viens de résoudre le problème.J'ai trouvé que les noeuds dans L'application.fichier de configuration mal configuré.

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

confirmez votre configuration dans le noeud <security> ,l'attribut "mode" valeur est "None". Si votre valeur est "Transport",l'erreur se produit.

Peut-il vous aider de ce lien dans Msdn Blogs:

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

avez-vous essayé d'utiliser clientVia pour voir le message envoyé, en utilisant SOAP toolkit ou quelque chose comme ça? Cela pourrait aider à voir si l'erreur provient du client lui-même ou d'ailleurs.

avez-vous vérifié les traces de la WCF? WCF a tendance à avaler les exceptions et à ne renvoyer que la dernière exception, qui est le temps mort que vous obtenez, puisque le point final n'a rien retourné de significatif.

vous recevrez également cette erreur si vous renvoyez un objet au client qui contient une propriété de type enum qui n'est pas définie par défaut et qu'enum n'a pas de valeur qui correspond à 0. I. e enum MyEnum{ a=1, b=2};

ressemble à ce message d'exception est très générique et peut être reçu pour une variété de raisons. Nous l'avons rencontré lors du déploiement du client sur les machines Windows 8.1. Notre client WCF fonctionne à l'intérieur d'un service windows et recherche continuellement le service WCF. Le service windows fonctionne sous un utilisateur non administrateur. Le problème a été résolu en paramétrant le clientCredentialType à "Windows" dans la configuration WCF pour permettre l'authentification de passer, comme dans le suivant:

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

Je ne suis pas un expert de la WCF mais je me demande si vous ne tombez pas dans une protection DDOS sur IIS. Je sais par expérience que si vous exécutez un tas de connexions simultanées d'un client simple à un serveur à un moment donné le serveur cesse de répondre aux appels comme il soupçonne une attaque DDOS. Il maintiendra également les connexions ouvertes jusqu'à leur temporisation afin de ralentir le client dans ses attaques.

connexion Multiple provenant de machines/IP différentes devrait ne pas être un problème cependant.

il y a plus d'info dans ce message MSDN:

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

découvrez les MaxConcurrentSession sproperty.