J'ai la manifestation standard de la remise en place dans mon service:
Cependant, il existe des cas où des exceptions sont levées sur le serveur et ni l'un ni l'autre appelé.
Voici un cas où l'exception du serveur n'est pas envoyée à iErrorhandler:
Définissez la créanceImout sur le serveur de liaison à 5 secondes.
sur le client fait ceci:
. Dans ce cas, l'erreur est lancée sur le serveur mais je ne trouve pas de moyen de le gérer (et de le loger). Je sais qu'une erreur est soulevée car si j'attache un débogueur sur le processus serveur et rompre toutes les exceptions, le débogueur rompt. J'ai trouvé d'autres cas similaires où des erreurs de faible niveau ne sont pas transmises à mon programme. Où puis-je accrocher mon code pour vous assurer que je peux gérer toutes les exceptions qui se produisent sur le serveur avant qu'ils ne soient retournés dans l'application client? Devrais-je mettre en œuvre mon propre iCHANNEL ou une autre interface basse niveau? merci
4 Réponses :
Le point est - si le serveur n'est pas accessible ou ne peut pas gérer le message, il n'y aura pas d'erreur sur le serveur - l'erreur apparaîtra sur le client ("TimeoutException" ou d'autres).
Donc, dans ces cas, l'IERRORHHANDLER sur le serveur ne vous aide vraiment pas - car l'erreur se produit vraiment sur le client (aucune connexion ne peut être faite, en raison du réseau vers le bas, ou de la typographie de l'adresse du serveur ou du SSTUFF ).
Donc sur le côté client, vous devez également utiliser Essayez .... Cattez autour de tous les appels de votre serveur.
marc
Pas correcte. C'est le serveur qui refuse de gérer l'appel car la réception a expiré. Par conséquent, l'exception est soulevée par le serveur. Comme je l'ai écrit, je peux attacher le débogueur sur le processus serveur, puis je vois que l'exception étant soulevée; Le problème est que ce n'est pas transmis à un gestionnaire avant qu'il ne soit retourné au client. J'ai besoin d'un moyen de gérer cette exception sur le serveur.
Ok, vous avez raison pour les réceptions - mais d'autres erreurs (ESP. Les erreurs de communication) peuvent se produire car le client tente de se connecter et n'atteindra jamais le serveur, et dans ces cas, IERRORHHANDLER sur le serveur est évidemment de rien, vraiment.
C'est vrai; Dans certains cas (le serveur est en panne par exemple), l'erreur ne se produira que sur le client. Mais pour ces cas où il se produit sur le serveur, je dois m'assurer que je les gère tous.
Configurez le traçage de diagnostic et vérifiez les journaux avec Outil de visualiseur de trace de service . Le lien contient des informations sur la configuration de la traçage également.
J'ai fait; Je vois l'erreur sur le serveur dans la trace. Je ne veux pas "tracer" ces cas, je veux "les gérer".
Le traçage aidera à comprendre où et pourquoi les exceptions se produisent est ce que je pense qu'il voulait dire (trace à la fois client et service). Manipulation correctement des exceptions au niveau de l'opération (essayez / attraper / lancer défausseXception) et un iErrorhandler doit couvrir vos bases (au moins je pensais). Lorsque cela pourrait tomber est un bug de la mise en œuvre de l'iErrorHandler ou un problème avec la configuration de service afin que la manipulation de l'exception ait une erreur et ne signalent pas avec précision le problème. Certainement intéressé à savoir si cela ne couvre pas toutes les bases Tho!
Comment voulez-vous "gérer" cette exception?
@John: Au minimum, je vais enregistrer l'erreur dans ma propre base de données d'erreur centralisée. Nous vous connectons toutes les erreurs qui se produisent sur nos serveurs. Ensuite, nous pouvons analyser régulièrement tous les journaux et trouver des problèmes potentiels à travailler. Nos clients ne le signalent pas toujours quand ils ont un problème avec les services Web, nous devons donc être proactifs. Je peux également vouloir renvoyer une exception différente au client dans certains scénarios spécifiques.
Utiliser des confesses. Ensuite, la faute peut être traitée à la fin du client.
http://msdn.microsoft.com/en-us/library /ms732013.celler
Ceci est également beaucoup mieux pour le débogage, car vous développerez souvent un client et ne voulez pas réduire le serveur à des fins de débogage.
À la fin du client, utilisez Essayez / Catch Blocks pour attraper toutes les exceptions / défauts. Il existe définitivement des erreurs qui ne peuvent pas être détectées sur la fin du serveur, telles qu'un problème de communication, vous devez donc gérer les erreurs sur l'extrémité du client de toute façon.
Si vous voulez une manipulation des erreurs centralisée, vous pouvez créer un service qui prend des messages sur toutes les erreurs, envoie l'erreur sur ce serveur et le connecte. Cela peut être utile si vous souhaitez créer un outil d'analyse de traçage / performance de messages centralisé / d'outil de journalisation de la performance et d'avoir un grand nombre de processeurs d'application, de serveurs, de clients, etc.
J'utilise aussi des failles. Mais dans ce cas particulier, l'erreur se produit la manière dont l'exécution de l'opération. Donc, je n'ai même pas eu de chance de convertir l'exception en une erreur erronée
Après de nombreuses recherches et expérimentations, la réponse est la suivante:
À ce moment-là (.NET 3.5) Il n'existe aucun mécanisme qui permet de gérer toutes les exceptions possibles pouvant survenir dans le contexte d'un appel WCF.
Exceptions qui se produisent lors de l'exécution de la méthode de service peuvent facilement être traitées avec:
Toutefois, pour les erreurs d'infrastructure de WCF de faible niveau, il n'y a pas de solution parfaite. La meilleure solution qui existe semble être de mettre en place un canal personnalisé pour attraper plus d'exceptions.
in Ce rapport de bogue Microsoft Connect , Microsoft confirme qu'il n'ya aucun moyen de gérer toutes les types d'erreurs d'infrastructure WCF.
in Ce fil sur les forums Microsoft WCF , il existe un exemple sur la manière d'implémenter un canal personnalisé. Cette solution ne fonctionne que pour HTTP, pas pour HTTPS. De plus, certaines erreurs d'infrastructure de la WCF ne sont pas capturées par le canal personnalisé (voir plus de détails dans ce fil spécifique).
@Anonymous Down-Vecteur: J'aimerais vraiment savoir pourquoi le vote au bas. C'est la bonne réponse. Si vous connaissez une meilleure réponse, veuillez le poster.
La liaison du serveur reçu ne doit pas être en jeu ici - ce ne serait que si cela a fallu plus de 5 secondes pour recevoir une réponse de l'appel à GetData (). Votre client dort pendant 10 secondes n'a aucun effet. En supposant que le service de test initial et la mise à jour de la liaison au serveur pour définir la créance à 5 secondes ne reproduit pas le problème. Quelle est la faute de votre réception sur le client? Je soupçonnerais une liaison / comportement de serveur mal configuré, surtout si vous n'intéressez pas au service de votre code. Activer le débogage de la WCF sur le client / le service et voir ce qu'il montre.
Comme décrit dans le MSDN, le serveur reçue est le maximum de temps que le serveur attendra un canal ouvert de veille. Dans ce cas, la quantité de temps est supérieure. L'exception sur le client est une MessageSecurityException qui possède une fauteException intérieure. La défaillance intérieure indique que la réception est dépassée.
Intéressant. Je suppose que cela pourrait également être un indice sur la raison pour laquelle cela a fonctionné sur le premier appel et non le second. Pouvez-vous transmettre un lien vers la documentation que vous vous référez à la réception? J'ai bien peur que ma compréhension de cette valeur soit imparfaite. Les docs que je me réfèrent sont msdn.microsoft.com/en-us/Library/ MS731299.aspx , merci!
Voici le doc: MSDN.MicRosoft.com / FR-US / Bibliothèque / ... .
@Zach: Je ne suis pas perplexe par le fait que le 2e appel ne fonctionne pas. C'est vraiment que je m'attends. Ce qui me puzzle que je n'arrive pas à trouver un moyen d'être averti sur le serveur. En fin de compte, les applications de mon client en savent plus sur les erreurs qui se produisent sur mon serveur que moi.
@Sly: ahhh ... je suis un idiot. 1) Je fixe la créancetime à 00:05:00 (minutes) dans mon scénario de test, donc je n'ai donc pas fait l'expérience du comportement que vous avez décrit jusqu'à ce qu'il y ait changé à 00:00:05 (secondes) et 2) Je n'ai jamais réalisé que la recevée est également affecté combien de temps un canal pourrait être inactif. Chaque client WCF que j'ai jamais écrit a toujours roulé un nouveau pour chaque demande. Jamais réalisé l'impact de garder une ouverture comme ça. Besoin de revoir davantage. Je suis aussi intéressé par ce que vous pouvez faire à ce sujet. Merci d'avoir souligné cela!