J'ai deux services WCF hébergés dans un seul service Windows sur une machine Windows Server 2003. Si le service Windows doit accéder à l'un ou l'autre des services de la WCF (comme lorsqu'un événement chronométré survient), il utilise l'un des cinq points d'extrémité de tuyaux nommés exposés (contrats de service différents). Le service expose également des points d'extrémité HTTP MetaDataAexchange pour chacun des deux services et des points d'extrémité Net.TCP pour les consommateurs externes sur le serveur.
Habituellement, les choses fonctionnent bien, mais de temps en temps, je reçois un message d'erreur qui ressemble à quelque chose comme ceci:
System.ServiceModel.endPointNotFoundException: il n'y avait pas d'écoute du point final à net.pipe: // localhost / ipdailyprocessing pouvant accepter le message. Ceci est souvent causé par une adresse ou une action de savon incorrecte. Voir InfardException, le cas échéant, pour plus de détails. ---> System.IO.PIPException: le point d'extrémité de la pipe 'Net.Pipe: // localhost / ipdailyProcessing' est introuvable sur votre machine locale. --- fin de la trace de la pile d'exception interne --- Trace de pile de serveurs: chez System.ServiceModel.Channel.PIPeconnectionInitiative.GetPIPENNAME (URI URI) à System.ServiceModel.channes.NameDPIPeconnectionPoolGistry.NameDPIPeconnectionPool.getpoolkey (adresse de terminaisonPointeddress, URI via) Au System.ServiceModel.Channel.ConnectionPoolHelper.establishConnection (Timespan Timeout) à System.ServiceModel.Channel.ClientFramingDuppexSessionChannel.onopen (TimePan Timeout) chez System.ServiceModel.channelages.comMunicationObject.open (TimePan Timeout) chez System.ServiceModel.Channel.ServicechanNel.onopen (Timespan Timeout) chez System.ServiceModel.channelages.comMunicationObject.open (TimePan Timeout) chez System.ServiceModel.Channel.ServicechanNel.Callopenonce.System.servicemodel.Channel.Servicechannel.icallonce.call (chaîne de servichannel, délai d'attente Timespan) à System.ServiceModel.Channel.ServicechanNel.CallonCemanager.Callonce (Timespan Timeout, Calloncemanager Cascade) à System.ServiceModel.Channel.ServicechanNel.Seuropéena (Timespan Timeout) à System.ServiceModel.Channel.ServicechanNel.Call.Call (String Action, Boolean Owway, Opération de proxyopérationRuntime, Object [] INS, OBJET OBTALLES, TIMEDOUT) À System.ServiceModel.Channel.ServicechanNel.Call.Call (String Action, Boolean Owway, ProxyOperationRontime Fonctionnement, Objet [] INS, Objet [] Outs) chez System.ServiceModel.Channel.ServicechanNelProxy.Invokeservice (IméthodcallMessage Methodcall, ProxyOperationRontime Funtime) chez System.ServiceModel.Channel.ServicechanNelProxy.invoke (message IMessage)Cela n'arrive pas de manière fiable, ce qui est fou, car je ne le répète pas quand je veux. Dans mon service Windows, j'ai également des événements chronométrés et certains auditeurs de fichiers, mais ce sont des événements assez rares. Quelqu'un a-t-il des idées pourquoi je pourrais rencontrer un problème? Toute aide serait grandement appréciée.
3 Réponses :
Je ne suis pas sûr de savoir si cela est germe à votre discussion, car je n'ai jamais utilisé les pipes nommées .net, mais je me souviens que les points d'extrémité de la prise TCP .NET TCP avaient un bug connu qui aboutit à des "points de terminaison occasionnels Terminé sans raison apparente »et, malheureusement, la réponse officielle de la SP était une" solution de contournement "qui impliquait de vérifier que le socket était toujours avant d'envoyer un message à l'intermédiaire et de la réinserver dans le cas échéant que ce n'était pas le cas. J'aimerais penser que les points d'extrémité de pipe nommés ne sont pas aussi peu fiables que les "critères de fin de TCP fiables", mais vous voudrez peut-être examiner la "panne de prise TCP périodique connue" pour voir si elle s'étend également à des tuyaux nommés. < / p>
Désolé que ce n'était pas vraiment une réponse, et je déteste suggérer de suggérer que vous deviez avoir à ajouter l'inefficacité de la vérification afin de vous assurer que c'est avant d'envoyer un message, etc.
Pouvez-vous fournir des liens vers le "bug connu" que vous décrivez et la "réponse officielle de la MS".
@Chris Dickson: Cela fait longtemps, mais je vais essayer de les trouver et les ajouter ici. Désolé si cela prend un moment.
D'accord, il s'avère que le virus que nous avions (qui, à l'époque, ne s'identifiant pas de manière appropriée) a depuis été isolé à la prise d'épuisement, qui est maintenant mieux documentée. Ainsi, sauf si vous épuisez vos prises, je doute que ma suggestion soit pertinente. Vous pouvez regarder si vous épuisez vos prises si vous ne l'avez pas déjà fait.
Vérifiez si le service "NET.PIPIPE STouter Adapter" est en cours d'exécution dans la console de gestion des services. Ceci est utilisé pour recevoir toute demande de pipe nommée.
J'ai aussi reçu ce message d'erreur, à l'aide de Net.Pipe hébergé sous IIS. IISRESET sur son propre ne rien corrigé, redémarrage de ce service + IISRESET Correction du problème.
J'ai eu une erreur similaire dans le passé et, si je me souviens bien, c'était quelque chose de mal avec les données transmises au service. Dans mon cas, le problème de l'affaire était en taille de données (j'ai utilisé le wshttpbinding, il existe donc une limite HTTP par défaut). La façon dont j'ai trouvé le problème était d'ajouter de la journalisation des méthodes connexes, de trouver les données problématiques et d'essayer de reproduire le problème dans un environnement convivial de débogage et de le faire se produire constamment avec des données que vous avez trouvées.
Dans mon cas, le message d'exception n'a pas été lié au problème, ce qui arrive parfois dans WCF.
Je viens de voir les questions post date :) Auteur: Si vous avez résolu le problème - veuillez poster la solution ou la raison du problème.
Je me débats avec le même problème, avez-vous déjà trouvé une solution? Périodiquement, cette erreur se produit. Dans certains cas, l'exception est 'le message n'a pas pu être envoyé car le service à l'adresse du point final' net.pipe: // localhost / D927B6B5-5994-4BD2-B92A-2FBDBAE18D28 / S Endemailworkflow / CRE ation 'est indisponible pour le protocole de l'adresse '. Le service n'est pas hébergé dans IIS afin que l'IIS / APPPOOL réinitialise.