Une connexion existante a été fermée de force par l'hôte distant - WCF
J'ai un service Web WCF qui fonctionne bien. Cependant, il y a un appel en particulier qui échoue - mais uniquement pour certains utilisateurs. L'appel est assez simple - c'est un appel pour obtenir une liste d'objets Personne.
Pour l'utilisateur A, cela fonctionne bien. Le service interroge la base de données, crée la liste des objets Personne et la renvoie à l'application appelante.
Pour l'utilisateur B, cela échoue. Ce qui est étrange, c'est que lorsque je débogue, le service semble fonctionner correctement. Il est capable d'interroger la base de données et crée l'objet List et le renvoie. Le service lui-même n'échoue jamais. Mais l'application cliente reçoit l'erreur "Une connexion existante a été fermée de force par l'hôte distant".
Pour moi, il semble que quelque chose se passe lorsque la couche service tente de regrouper les données au format XML pour les renvoyer à l'application appelante. Je pense que cela doit être un problème lié aux données, car l'appel fonctionne bien pour les autres utilisateurs. J'ai visuellement examiné les données et je ne vois vraiment rien d'étrange. Une hypothèse est que les données pour l'utilisateur B contiennent des caractères cachés géniaux ou quelque chose qui provoque donc la fermeture inattendue du service. Quelque chose comme ca.
Des idées?
La meilleure chose que j'ai trouvée pour diagnostiquer de telles choses est la visionneuse de trace de service. C'est assez simple à configurer (en supposant que vous puissiez éditer les configurations):
http://msdn.Microsoft.com/en-us/library/ms732023.aspx
J'espère que cela t'aides.
J'ai eu ce problème parce que mon site Web n'avait pas de certificat lié au port SSL. Je pensais en parler parce que je ne trouvais pas cette réponse dans le site Web Google et que cela me prenait des heures pour le comprendre. Rien n’apparaissait dans l’observateur d’événements, ce qui était vraiment génial pour le diagnostiquer. J'espère que cela évite la douleur à quelqu'un d'autre.
J'ai vu cela une fois. Les utilisateurs demandent-ils différentes quantités de données? J'ai constaté que même si vous pouvez configurer une liaison pour les charges utiles de données (c'est-à-dire maxReceivedMessageSize), la variable httpRuntimemaxRequestLength l'emporte sur le paramètre WCF. Par conséquent, si IIS tente de répondre à une demande dépassant cette valeur, il présente ce comportement.
Pensez-y comme ceci:
Si maxReceivedMessageSize correspond à 12 Mo dans votre comportement WCF et si maxRequestLength correspond à 4 Mo (valeur par défaut), IIS l'emporte.
J'ai trouvé que vous pouvez obtenir cette erreur si l'objet renvoyé a uniquement les propriétés automatiques du getter initialisées dans le constructeur (avec la syntaxe C # 6.0).
Je pense que cela est dû à la désérialisation des objets WCF côté client à l'aide d'un constructeur sans paramètre, puis à la définition des propriétés de l'objet. Il doit avoir une set available (il peut être privé) pour remplir l'objet, sinon cela échouera.
Je viens d'avoir cette erreur maintenant dans le serveur uniquement et la solution consistait à définir un attribut maxItemsInObjectGraph dans wcf web.config Sous la balise <behavior>:
<dataContractSerializer maxItemsInObjectGraph="2147483646"/>
J'ai attrapé la même exception et trouvé un InnerException: SocketException. dans la trace de svclog.
Après avoir consulté le journal des événements de Windows, j'ai constaté une erreur provenant de la classe System.ServiceModel.Activation.TcpWorkerProcess.
Vous hébergez votre service wcf dans IIS avec netTcpBinding et le partage de port?
Il semble y avoir un bogue dans la fonctionnalité de partage de port IIS, vérifiez le fix :
Ma solution consiste à héberger votre service WCF dans un service Windows.
Après avoir tiré mes cheveux pendant environ 6 heures de cette erreur complètement inutile, mon problème est que mon data transfer objects était trop complexe. Commencez avec uber propriétés simples comme public long Id { get; set;} c'est tout ... rien d'extraordinaire.
J'ai le même problème. Ma solution est la suivante:
Si vous utilisez LinQ2SQL dans votre projet, ouvrez votre fichier dbml dans Visual Studio et définissez le mode de sérialisation sur "Unidirectionnel" le
Dans mon cas, c'était aussi avec la sérialisation. J'ai besoin d'ajouter [KnownType(typeof(...)] pour toutes les classes susceptibles d'apparaître dans la sérialisation.
Le problème que j'avais était aussi avec la sérialisation. La cause était certaines de mes classes DTO/business et les propriétés ont été renommées ou supprimées sans mettre à jour la référence de service. Je suis surpris de ne pas avoir reçu un contract filter mismatch error à la place. Mais la mise à jour de la référence de service a corrigé l'erreur pour moi (même erreur que OP).
Ce problème commençait à se produire lors du débogage d'un projet Web vers un service Web dans la même solution. Le service Web renvoyait des réponses que le projet Web ne pouvait pas comprendre. Cela fonctionnerait à nouveau à certains moments, puis s'arrêterait à nouveau.
C’est parce qu’il n’y avait pas de référence explicite entre ces projets et que, par conséquent, le service Web n’était pas construit lorsqu’il a appuyé sur F5 pour lancer le débogage. Une fois que j'ai ajouté cela, les erreurs ont disparu.