Traçage WCF. Comment puis-je obtenir la raison exacte de la fermeture de la connexion?
Dans mon service WCF, lors de la tentative de transfert de données volumineuses, j'ai toujours une erreur: La connexion sous-jacente a été fermée: La connexion a été fermée de façon inattendue
Je veux savoir quel est le motif invoque cette erreur, j'ai donc mis en place WCF Traçage et peut lire traces.svclog fichier.
Le problème, c'est que je peux voir dans ce fichier beaucoup d'informations sur les flux de processus, je peux voir l'heure exacte à laquelle l'exception est apparu, mais je ne vois pas la raison exacte pour que. Est-ce dû à MaxReceivedMessageSize ou quelque chose comme ça.
Est-ce donc que traces.svclog ne peut pas contenir de telles informations ou suis-je en train de faire quelque chose de mal?
Comment ces informations pourraient être obtenues?
Modifié (ajout):
De mon côté serveur d'application.config:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="NAVBinding_ICustomer_Service"
closeTimeout="01:50:00"
openTimeout="01:50:00" receiveTimeout="01:50:00" sendTimeout="01:50:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="2147483647" maxBufferPoolSize="2147483647"
maxReceivedMessageSize="2147483647" messageEncoding="Text"
textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name = "Customer_Service" behaviorConfiguration="returnFaults">
<endpoint name="NAVBinding_ICustomer_Service"
address = "http://localhost:8000/nav/customer"
binding = "basicHttpBinding"
bindingConfiguration= "NAVBinding_ICustomer_Service"
contract = "NAVServiceReference.ICustomer_Service"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="returnFaults" >
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>Modifié (ajout):
Qu'est-ce que le droit et la meilleure façon de tourner la WCF service à partir d'une "boîte noire" pour un facilement troubleshooted service, qui indique la raison pour laquelle quelque chose ne va pas l'attendre?
Quels sont les outils, les techniques que vous utilisez pour résoudre les service WCF?
source d'informationauteur rem
Vous devez vous connecter pour publier un commentaire.
En ignorant les problèmes avec le maxRequestLength (qui ont été traitées par d'autres),
Je vais donc essayer de répondre à votre question initiale sur la façon de résoudre la WCF.
Si vous êtes déjà à l'aide de la Visionneuse de Trace de Service (je ne pouvais pas dire à partir de la question
si vous venez de vous les afficher par la main) - il est possible que tous les détails ne sont pas
va dans le fichier.
Quand je veux vraiment faire de hardcore, j'permettre à tous les paramètres de journalisation pour
l'enregistrement des messages. (Cela va générer quelques grands journaux de service mais ne laissez pas
c')
Si vous n'êtes pas à l'aide de Microsoft Visionneuse de Trace de Service je recommande que. Il
donne toutes les informations dont j'ai besoin pour traquer ceux délicat message poignée de main, message
la taille des exceptions, etc. Voici une référence MSDN pour vous aider à démarrer
http://msdn.microsoft.com/en-us/library/aa751795.aspx
Trace des interactions qui ont des problèmes potentiels sont hilighted en jaune sur la
gauche, et le volet en haut à droite normalement hilight l'exceptionnel
service de l'événement en rouge. Parfois, vous obtiendrez de nombreux problèmes, comme l'intérieur des
erreur de cascades à travers le service de pile, mais vous pouvez voir tout cela dans le
visionneuse de trace.
Si vous n'avez rien dans votre serveur de service "journal", alors il est possible que des exceptions sont entièrement au client de bout en théorie, vous pouvez dépasser certaines du client
côté sécurité, les paramètres (taille de message, etc) avant qu'un message a bien atteint le
service web - mais les problèmes du client sont généralement plus faciles à repérer car vous savez que vous avez seulement à vous soucier de l'édition du fichier de configuration sur le client final (c'est à dire ce n'est pas parce que de toute interaction entre le client et le serveur les paramètres).
J'ai passé les 2 derniers jours à essayer de trouver pourquoi je suis "La connexion sous-jacente a été fermée: La connexion a été fermée de manière inattendue" avec un appel de la méthode de retour avec plus de données vs lorsqu'il n'est pas tellement de données (c'est à dire, il fonctionne bien avec de petits ensembles de données renvoyées uniquement).
Mon erreur messsages sont légèrement différentes (peut-être en raison de cadre différences), mais je voulais partager la cause que j'ai trouvé. Tout d'abord, je tiens à préciser que pendant le suivi et l'augmentation de la taille de certaines choses dans les fichiers de configuration étant donné que les réponses ci-dessus peut être utile pour le suivi de la WCF erreurs, ces choses n'ont rien fait pour m'aider à déterminer la véritable cause de l'erreur.
Simplement en regardant l'exception et de la chaîne, j'ai pu voir la suite de racine, d'erreur:
"Une connexion existante a dû être fermée par l'hôte distant" - c'était un Système.Net.Les Sockets.Exception socketexception
Aller jusqu'à l'appel de la chaîne d'alors:
"Impossible de lire les données de la connexion de transport: Une connexion existante a dû être fermée par l'hôte distant." - un Système.IO.IOException, puis
"La connexion sous-jacente a été fermée: Une erreur inattendue s'est produite sur une de recevoir." - un Système.Net.WebException, puis, enfin, ce qui était l'exception interceptée du message,
"Une erreur s'est produite lors de la réception de la réponse HTTP . Cela pourrait être dû à la point de terminaison de service de liaison de ne pas utiliser le protocole HTTP. Cela pourrait aussi être dû à une requête HTTP contexte été interrompue par le serveur (éventuellement à cause de l'arrêt). Voir les journaux du serveur pour plus de détails." - un Système.ServiceModel.CommunicationException
L'activation du traçage affichage des journaux de suivi avec le traceviewer afin de ne rendre cela plus facile à voir, mais ne m'a jamais dit la véritable cause de ma "Une connexion existante a dû être fermée par l'hôte distant" erreur.
Dans mon cas, mon service WCF est hébergé sur IIS6 et seulement quand j'ai contacté notre soutien institutionnel en charge de ces serveurs et leur a demandé de regarder dans les journaux des événements système, je n'ai immédiatement voir la réponse - un Système.OutOfMemoryException!
Mon WCF service s'exécute dans un alloués 200 MO de RAM et ma méthode était en train de consommer plus que cela. J'ai regardé dans ma méthode et finis par trouver un bloc de code qui aurait été à l'extérieur de/au-dessous du bloc (en boucle), il a été dans. . ..donc j'ai eu une exponentielle type de collection générés dans ma méthode.
Espère que cela peut aider les autres.
Pour répondre à votre question comment créer facilement un mal tourné service WCF. Une façon est de minimiser le nombre d'erreurs potentielles, de sorte que vous avez de moins en moins de choses à regarder pendant le dépannage.
Il existe deux principales sources d'erreurs:
Erreurs de configuration sont souvent dues à une inadéquation entre le client et le service. Pour éviter cet endroit à toutes les configurations possibles dans un BindingConfiguration et les copier et les utiliser à la fois le client et le serveur. Je pense que c'est effectivement là où est ton problème, vous êtes à la mise à jour du service web.config, avec les choses qui doivent également être dans la config du client. Pour eaxmple la taille max, ou d'avoir mis en l'un et en continu dans l'autre.
Erreurs jeter par le service devrait être jeté comme un FaultException et défini dans le Contrat comme un FaultContract.
Pour les autres erreurs, vous devez regarder à l'état de trace.svclog fichier comme décrit dans d'autres posts. Vous avez besoin également de consulter le journal des événements et le journal IIS, les appels peuvent être bloqués avant qu'ils n'atteignent le service WCF.
Essayer de régler le maxRequestLength propriété:
Pour ceux qui sont encore en se ce problème - comme d'habitude il y a un couple absolument crucial choses en reste de la discussion ci-dessus, sans laquelle il n'y a aucun espoir de trouver une réponse. Voici ce qui m'a pris 3 heures de fouiller sur internet pour trouver des.
Pour récapituler:
Tout d'abord, j'ai eu le redoutable ne Trouve Pas d'erreur à l'aide de la WCF de Silverlight service. Non, ce n'est pas parce que le service n'est pas trouvé. J'ai été en mesure d'étape à travers le service méthode clair à la fin, y compris le retour. Puis le côté client a obtenu une exception dans l'asynchrone en Fin partie de l'appel. Aucune explication. Il n'a RIEN à voir avec les liaisons, etc.
Puis j'ai trouvé les messages des forums comme celui-ci sur l'utilisation de la visionneuse de trace. S'avère que j'avais déjà configuré, mais n'obtient pas de trace (alors j'ai pensé que mon service doit être ok, esp. depuis que j'ai pu retrouver thru). Mal, bongo garçon. Ensuite, j'ai trouvé un autre message disant un fait peu connu est que si vous configurez un écouteur de trace d'écrire "C:\logs\mylog", vous DEVEZ d'abord créer C:\logs par la main. Il ne le fera pas pour vous.
Ok, maintenant, je reçois le journal et de le ramener dans traceviewer afin. Après quoi, je reçois un message d'erreur "" à propos d'un sans terminaison de chaîne. Trente minutes plus tard, j'ai trouver un autre message disant: oh, tout le monde sait que vous devez d'abord mettre fin à votre local serveur de dev, afin de débusquer les derniers messages. Vous savez, ceux qui ont réellement vous dire ce qui s'est passé?
Maintenant j'arrive à les vraies erreurs et de regarder chacun d'eux: le fait de Lancer une Exception, RequestContext abandonné, et n'a pas pu Envoyer de message de Réponse http. Seule la première des questions. Sauf bien sûr lorsque l'on regarde le volet inférieur, il m'a donné aucune information utile à tout, sauf à dire qu'il y avait une erreur de Sérialisation. Euh, "où", ce serait bien.
À mon wit's end, j'ai soudain avis il y a un petit onglet XML dans le volet inférieur, juste à côté de la "Formatés" onglet. Quand je clique sur que, pour ma ThrowingAnException message, n'est - ce pas un immense dépotoir à un très spécifiques message qui m'a conduit droit au problème:
Système.ServiceModel.CommunicationException, Système.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Il y avait une erreur lors de la tentative de sérialiser paramètre :GetTimecardsWithAlertsResult. Le InnerException message était " valeur d'Enum '0' n'est pas valide pour le type 'Pointeuse.Web.ShiftManager.AlertType " et ne peut pas être sérialisé. S'assurer que les valeurs enum sont présents et sont marquées avec EnumMemberAttribute attribut si le type a DataContractAttribute attribut.'. Veuillez voir InnerException pour plus de détails.
Le problème était que je n'avais pas initialisé un enum-fonction membre d'une classe, de sorte qu'il était de 0, ce qui n'était PAS un de mes autorisé les valeurs de l'enum. Très simple à corriger.
Et clairement, très simple pour Microsoft pour détecter, étant donné que la grande quantité d'informations qu'ils ont réussi à caché des regards indiscrets pendant 3 heures.
Voici une idée de Microsoft - que diriez-vous venez de proposer un moyen de rattraper ces erreurs et l'importance d'exception-message serveur? Ou les laisser entièrement à passer à travers pour le client Silverlight? Vous, de faire il est facile de voir ce qui se passe, afin que je puisse résoudre ce problème simple en 3 secondes il le mérite, au lieu des 3 heures, je dois charger mon client de ne rien faire d'utile?
Oh, je sais. C'est vraiment dur parce que c'est un appel asynchrone via http, et la moyenne de l'ol sur internet, il nuire à votre cerveau. Mais devinez quoi? Vous êtes Microsoft. Vous avez illimité dans le temps et de l'argent. Et vous avez un impact sur des millions de personnes. Quand tu vis avec ce type de s**t, comme vous le faites avec des milliers de scénarios où vous juste ne pouvait pas être dérangé, vous affecte des centaines de milliers de développeurs à travers la planète.
Regardez autour de vous sur StackOverflow. Voir comment de nombreuses personnes à travers le monde, des gens intelligents à essayer d'écrire des logiciels utiles, des choses importantes, qui sont tout simplement pas immergé dans l'incroyable minutie comme ci-dessus, parce que, vous savez, ils ont un réel travail à faire.
Multiplier mes 3 heures sur ce problème stupide fois des dizaines de milliers de développeurs de temps de 30 à 40 épisodes de ce genre de conneries dans une année typique, et vous verrez de quoi vous provoquer des catastrophes. C'est bien de dire "c'est pourquoi nous faire payer le gros lot", mais pensez à ce que réelle du bon travail, nous pourrions tous être d'accomplir dans le monde si chaque fois que l'on tourne autour de nous de ne pas avoir à plonger jusqu'à 3 heures de s**t-trou que vous avez creusé pour nous?
Microsoft, vous qui êtes mauvais pour la programmation, mauvais pour les affaires, et mauvais pour l'humanité. Je ne m'inquiète pas combien d'ordinateurs exécuter votre logiciel. Vous devez faire mieux. Veuillez commencer à agir comme vous comprendre combien vous l'abus des serviteurs des gens qui travaillent dur dans le monde, dans chaque pays, à chaque jour. Et comment beaucoup mieux un endroit que vous pourriez faire si vous avez juste a agi comme il importait de bien faire les choses.
Tim Johnson
Vous devriez obtenir une communication spécifique à l'exception du côté client.
Je pense que cette exception que vous décrivez est une exception est levée, après avoir essayé de réutiliser le client après qu'il a des failles.
Essayez ceci:
Je ne pense pas que vous avez besoin de traçage. Essayez les et vous serez en mesure de voir exactement erreur de communication.
Oh, et BTW, est-ce votre client est l'application Silverlight?
Si oui, alors il est un peu plus compliqué... découvrez cette article.