Question Quelle est la cause de cette erreur de connectivité sporadique du service Web IIS 7?


Lors d'occasions sporadiques, le message d'erreur suivant s'affiche lorsque vous tentez d'appeler un service Web .asmx à partir d'une application cliente .Net:

"La connexion sous-jacente a été fermée: une connexion censée être maintenue en vie a été fermée par le serveur. Impossible de lire les données à partir de la connexion de transport: une connexion existante a été fermée de force par l'hôte distant."

Par sporadique, je veux dire que cela peut arriver zéro, une fois tous les quelques jours, ou une demi-douzaine de fois par jour pour certains utilisateurs. Cela ne se produira jamais lors du premier appel de service Web d'un utilisateur. Et l'appel suivant (généralement le même) fonctionnera toujours immédiatement après l'échec. Les échecs se produisent avec diverses méthodes du service et se produisent généralement entre 15 et 20 secondes (selon le journal) à partir du moment de la demande.

La recherche dans l'appel du journal du site IIS indique l'un ou l'autre des codes d'erreur Windows suivants:

121: le délai d'attente du sémaphore est écoulé.

1236: la connexion réseau a été interrompue par le système local.

Quelques détails supplémentaires sur l'environnement:

  • Exécution sur une batterie de serveurs Web de réseau interne composée de deux serveurs exécutant IIS7 sur un système d'exploitation Windows Server 2008. Ces problèmes ne se sont pas produits lors de l'exécution dans une ancienne batterie de serveurs Web exécutant Windows Server 2003 sur une ancienne batterie de serveurs Web IIS6 (et nous utilisons une seule instance IIS6 / 2003 pour nos environnements de développement et de stockage intermédiaire sans problème). EDIT: De plus, toutes ces instances de serveur sont des machines virtuelles VMWare, ne sachant pas si cela est une surprise ou non.

  • Le service Web est un service Web .asmx compilé .Net 2.0 / 3.5 qui possède son propre pool d'applications (.Net 2.0, pipeline intégré). Seule l’authentification Windows est activée.

  • Nous avons un autre service Web sur la batterie qui utilise le même chemin physique que le service principal, la seule différence étant que l'authentification de base est activée. Ceci est utilisé pour une partie de notre système ERP. Avoir essayé d'utiliser le même et un pool d'applications différent - aucun effet sur l'erreur. Ce site ne frappe pas aussi souvent que le site principal et n'a jamais eu d'erreur.

  • Comme mentionné, l'erreur ne se produira que lorsqu'elle est appelée depuis le client .Net, et non depuis d'autres applications. L'application client crée toujours un nouvel objet de service Web pour chaque demande et définit les informations d'identification du service sur System.Net.CredentialCache.DefaultCredentials.

    L'application est soit déployée localement sur un client, soit exécutée dans une session de serveur Citrix. Les utilisateurs exécutant Citrix ne semblent pas rencontrer le problème, mais uniquement les clients déployés localement. Les serveurs Citrix et la batterie de serveurs Web sont situés au même emplacement physique et dans la même plage d'adresses IP (10.67.xx.xx). Les clients déployés localement et rencontrant l'erreur se trouvent ailleurs (10.105.xx.xx, 10.31.xx.xx).

J'ai consulté les journaux du système d'exploitation pour voir si je pouvais voir le moindre problème, mais rien ne dépasse vraiment.

EDIT: En fait, j'ai moi-même rencontré l'erreur il y a un peu. J'ai décidé de consulter à nouveau les journaux et j'ai constaté qu'il y avait une entrée du journal de sécurité "Audit Failure" au même moment (entrée du journal IIS à 1:39:59, entrée du journal des événements à 1:39:50). Pas sûr que ce soit une coïncidence ou non, je devrai consulter les journaux des erreurs précédentes. Je suis probablement à la recherche de pailles mais les détails:

Nom du journal: Sécurité Source: Microsoft-Windows-Security-Auditing Date: 7/8/2009 13:39:50 Numéro d'événement: 5159 Catégorie de tâche: Connexion à la plateforme de filtrage Niveau: Information Mots-clés: Échec de l'audit Utilisateur: N / A Ordinateur: is071019. <******>. Net La description: La plate-forme de filtrage Windows a bloqué une liaison vers un port local.

Informations sur l'application:     Identifiant de processus: 1260     Nom de l'application: \ device \ harddiskvolume1 \ windows \ system32 \ svchost.exe

Informations sur le réseau:     Adresse source: 0.0.0.0     Port source: 54802     Protocole: 17

Informations sur le filtre:     ID du filtre d'exécution: 0     Nom du calque: Affectation de ressources     Identifiant d'exécution de couche: 36

J'ai également essayé d'utiliser le suivi des demandes ayant échoué dans IIS7, mais l'appel de service n'arrive jamais à l'endroit où FRT peut le capturer (même si cet échec est enregistré dans le journal du service Web).

Le groupe d'infrastructure réseau a indiqué qu'il avait extrait le DNS et que tous les paramètres de la carte réseau étaient corrects; il n'y avait donc pas de "battement". Tout se passe. Je ne suis pas sûr qu'ils aient vérifié tous les serveurs de contrôleur de domaine pour voir si cela pouvait poser problème.

Des idées? Ou d'autres stratégies de débogage pour aller au fond des choses? Je ne suis que le développeur en charge du logiciel et je ne sais pas vraiment ce qu'il faut examiner du point de vue de la mise en réseau, même si cela me semble être un problème de mise en réseau basé sur ce qui se passe.

Merci d'avance pour votre aide.


6
2017-07-06 20:52


origine




Réponses:


Vous pouvez créer une page qui échouera avec une erreur lorsque cela se produit (essayez catch), puis utilisez WCAT pour simuler diverses conditions de charge. Espérons que vous puissiez voir un motif ou au moins voir s'il est lié à la charge. Sinon, je construirais simplement quelque chose dans le client .Net qui détecte ce problème et tente simplement de réessayer la demande, de sorte qu'elle soit transparente pour l'utilisateur.


1
2017-07-07 00:34



Je ne pense pas que cela soit lié à la charge car j'ai vu des cas d'erreur se produire avec seulement 1 ou 2 personnes frappant le serveur. Je ne pense pas que cela soit lié à une période d'inactivité, car l'erreur est survenue avec une activité élevée sur le site. Bonne idée sur l'idée de «réessayer», même si j'aimerais vraiment savoir pourquoi cela se produit.
Pas sûr de pouvoir commenter mon commentaire, mais je viens de modifier la question ci-dessus pour y inclure des informations sur un échec récent et un événement de sécurité pouvant être lié.


Devez-vous activer la plate-forme de filtrage Windows? Si vous êtes autorisé à le désactiver, cela devrait éviter cette erreur d'audit; si vous devez l'activer, ils peuvent peut-être faire une exception pour vous permettre de désactiver la catégorie d'audit - voir: http://msdn.microsoft.com/en-us/library/bb309058(VS.85).aspx

Si vous devez laisser le PAM activé et intact, cela ne vous aidera pas.


1
2017-09-17 21:42



Je ne suis pas sûr de savoir comment désactiver WPF ou s'il est autorisé. Est-ce qu'une partie du pare-feu Windows? Le WF est désactivé sur ces machines (mais le service sous-jacent est en cours d'exécution depuis IPSec, je pense, doit être en cours d'exécution). Je pense que l’audit est une erreur: j’ai vu d’autres publications sur cette erreur et MS a publié un article de la Base de connaissances pour la corriger: support.microsoft.com/kb/969257. Donc, je suppose que ce n'est pas la cause du problème fondamental. Je pense toujours que c'est en quelque sorte lié au réseau / domaine, mais comme l'erreur ne survient pas pour 95% des utilisateurs, cela ne pose pas de problème pour le groupe de réseau.


Je rencontre également la même situation sporadique dans un environnement de production uniquement. Certaines des suggestions que j'ai trouvées mais pas encore validées consistent à désactiver Http Keep-Alive sur le serveur ou à désactiver la requête Web. Voir http://support.microsoft.com/kb/819450

Je prévois de tester cela dans un environnement de test.


0
2017-10-26 22:29