Comment: service Web et gestion des délais d'expiration des clients dans le service Web?

Question

J'essaie de consigner ce qui se passe lorsque le client se bloque lors d'un appel de service Web.

Jetez un coup d'œil au code HelloWorld ci-dessous. C'est ce que je souhaite faire, mais il semble que IsClientConnected ne fonctionne pas car il retourne toujours vrai.

[WebMethod] 
public string HelloWorld() { 
    //.. Do the Webservice stuff 
    if (!Context.Response.IsClientConnected) { 
     //Log some vital info about this call that timed out... 
    } 
    return "The WebService Result"; 
} 

Est-ce que quelqu'un connaît une autre façon de vérifier l'état de l'appel du service Web?

Lorsque des clients se déconnectent d'un appel de service Web, aucune exception n'est générée dans le service Web. Le code continue de s'exécuter jusqu'à ce qu'il soit fait et renvoie ensuite son résultat dans le néant (lorsque la connexion est fermée).

Answer 1

Je m'attendrais à ce que chaque appel de service Web soit une demande/réponse. En cas d'erreur telle que l'indisponibilité du service ou les délais, je m'attendrais à une exception.

Alors, est-il possible d'entourer l'appel avec un try try?

Answer 2

Il est préférable de s'abonner à une sorte d'événement que de vérifier un drapeau. Fondamentalement, ASP.NET est en train de tuer la requête car elle prend plus de temps que la valeur de délai d'attente configurée (paramètre executionTimeout dans l'élément httpRuntime). Cependant, je ne suis pas sûr si un tel événement provient de l'environnement d'exécution ASP.NET. Apparemment, il ne soulève aucune exception non plus. Il semble donc y avoir une déconnexion entre votre service et le runtime ASP.NET dans ce cas particulier. Je serais intéressé de savoir s'il y a un moyen/un truc pour accomplir ce que vous recherchez.

En attendant, vous pouvez consulter les compteurs de performance ASP.NET. Il y en a un appelé "Demandes expirées". Cela peut inclure des demandes qui ont expiré pendant l'attente dans une file d'attente ou pendant l'exécution. Vous pouvez lire ce compteur de performance pour votre service Web au début et à la fin de votre méthode Web. Si le nombre a sauté, cela signifie une demande juste un délai. Cela peut ne pas signifier que le saut correspond à cette requête particulière mais dans tous les cas, vous pouvez toujours enregistrer des informations telles que les paramètres passés à la méthode web, le temps écoulé, etc. Vous pouvez également augmenter la valeur de executionTimeout dans web.config pour permettre plus de temps pendant que vous essayez d'optimiser votre méthode Web pour qu'elle s'exécute plus rapidement si vos clients ont besoin d'une solution immédiate.

S'il s'agit d'un service Web asmx, vous pouvez examiner l'événement Session_End dans global.asax. Il peut être appelé lorsque ASP.NET supprime la demande.

Juste quelques pensées.

Answer 3

Cela dépendra des détails de l'infrastructure de service Web que vous utilisez. D'après ce que vous montrez, je ne serais pas surpris si vous n'aviez aucun mécanisme pour le détecter.

Considérons qu'en général, un service Web ne doit même pas utiliser un transport tel que HTTP, vous pouvez répondre via des files d'attente, ou même par e-mail. En général, vous ne pouvez pas, en tant que serveur, mettre en œuvre un simple service Web, assurez-vous que votre client a vu la réponse. Que voulez-vous déduire si votre test a fonctionné? Au moment où vous avez fait le test, il est là, une nanoseconde après que vous ayez décidé de ne pas vous connecter, mais avant votre retour, il est parti. Il n'y a pas de relation transactionnelle entre Client et Serveur en SOAP/HTTP simple.

Il existe des normes de service Web supplémentaires pour résoudre certains de ces problèmes, mais vous devez généralement concevoir vos services Web en supposant que l'appelant ne puisse pas voir la réponse. (peut-être que vous fournissez également des services de statut, de sorte qu'un client peut déposer et ensuite revenir et demander «avez-vous traité l'ordre» 345 »).

S'il vous plaît dites-nous ce que vous voulez réaliser avec cette journalisation, peut-être que quelqu'un a une approche de conception pour vous aider.

Answer 4

Le protocole HTTP n'a aucune spécification sur la façon dont le serveur peut exécuter un ping sur le client. Le sens de IsClientConnected - pour vérifier s'il existe une requête "insatisfait" pour rendre HttpResponse. Et peut-être (je ne suis pas sûr) si le client supporte keep-connection-alive. Pensez à tirer l'architecture - vous aviez une méthode unidirectionnelle, et un chien de garde du côté client pour vérifier périodiquement si la méthode est faite.

Answer 5

Je pense que pour que IsClientConnected renvoie false, la partie de votre code de service Web qui dit «// .. Do the Webservice stuff» devrait être plus longue à exécuter que le paramètre de délai d'attente du client. Vous pouvez probablement simuler cela en définissant le délai d'expiration du client sur 60 secondes et en ajoutant Thread.Sleep (70000) dans votre code de service Web avant l'appel IsClientConnected.

Cependant, je ne pense pas que cela aboutirait à ce que IsClientConnected renvoie false. La temporisation d'une demande de service Web et la réinitialisation de la connexion au serveur sont deux bêtes différentes. Si Response avait une méthode appelée IsClientStillWaitingForThisWebServiceCallToReturn, cela pourrait faire ce que vous voulez.

Je pense que vous pouvez obtenir IsClientConnected pour renvoyer false si vous avez déconnecté physiquement le client du réseau alors que la méthode de service Web était encore dans la partie avant la vérification IsClientConnected, mais je suppose que ce n'est pas ce que vous voulez.

Answer 6

Je ne crois pas qu'il y aura une exception en général. Même si le service renvoyait une réponse longue, telle que la fenêtre de transmission sortante se fermait et expirait en attendant d'être en mesure d'envoyer des octets, tout cela se produirait après que la méthode Web était revenue à ASP.NET.

Ce que vous devez faire est d'apprendre quelles méthodes Web prennent trop de temps. Vous pouvez commencer à le faire en activant le suivi, comme indiqué dans "Enabling Tracing in ASP.NET Web Services". Vous devrez peut-être aller plus loin et profiler le service pour voir où le temps est passé.

Vous devriez également regarder attentivement les journaux d'événements. Recherchez en particulier les événements d'avertissement provenant de la source d'événement "ASP.NET". Ceux-ci viennent de ASP.NET Health Monitoring. Je vous recommande de vous familiariser avec le système de surveillance de la santé, car vous constaterez qu'il fait beaucoup de choses que vous auriez à écrire vous-même, simplement au prix de la configuration.

Answer 7

J'ai créé un client de test simple et tournai ma demande de délai d'attente dans 100ms

 HttpWebRequest MakeRequest = (HttpWebRequest)WebRequest.Create("http://localhost:55959/ScanServer.asmx"); 
     if (MakeRequest == null) 
     { 
      throw new Exception(); 
     } 
     HttpWebResponse PostResponse = null; 

     MakeRequest.Method = "POST"; 
     MakeRequest.AuthenticationLevel = System.Net.Security.AuthenticationLevel.None; 
     MakeRequest.UserAgent = "testing"; 
     MakeRequest.Timeout = 100; 
     MakeRequest.ContentType = "application/soap+xml; charset=utf-8;"; 

     try 
     { 
      byte[] PostBytes = UTF8Encoding.UTF8.GetBytes(PostData); 
      MakeRequest.ContentLength = PostBytes.Length; 

      Stream RequestStream = MakeRequest.GetRequestStream(); 
      RequestStream.Write(PostBytes, 0, PostBytes.Length); 

      PostResponse = (HttpWebResponse)MakeRequest.GetResponse(); 
     } 
     catch 
     { 
      throw; 
     } 

l'intérieur d'un appel WebService SOAP lors du débogage j'ai attendu sur un point de rupture jusqu'à ce que le client a reçu l'exception du délai d'attente. La valeur Context.Response.IsClientConnected a ensuite été définie sur false. J'ai également utilisé Fiddler pour envoyer une requête et quand au point de rupture du serveur j'ai interrompu la session. Encore une fois, la valeur a été définie sur false. Je n'arrive pas à comprendre pourquoi vous voyez un timeout sans pouvoir enregistrer les données lors de la vérification de IsClientConnected sauf si le timeout est dans la connexion initiale à votre serveur.