Comment : Service web et gestion des délais d'expiration du client dans le service web ?

Question

Je suis en train d'essayer de consigner ce qui se passe lorsque le client obtient un délai d'attente lors d'un appel à un service Web.

Jetez un œ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() {
    //.. Faire des choses avec le service Web
    if (!Context.Response.IsClientConnected) {
        //Consigner des informations essentielles sur cet appel qui a expiré...
    }
    return "Le résultat du service Web";
}

Est-ce que quelqu'un sait un autre moyen de vérifier l'état de l'appel au service Web?

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

Answer 1

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

Ce que vous devriez faire, c'est apprendre quelles méthodes web prennent trop de temps. Vous pouvez commencer par activer la trace, comme indiqué dans "Activation de la trace dans les services web ASP.NET". Vous devrez peut-être aller plus loin et profiler le service pour voir où le temps est passé.

Vous devriez également examiner attentivement les journaux d'événements. En particulier, recherchez les événements d'avertissement de la source d'événement "ASP.NET". Ceux-ci proviennent de la surveillance de la santé ASP.NET. Je vous recommande de vous familiariser avec le système de surveillance de la santé, car vous pourriez constater qu'il effectue de nombreuses tâches pour vous que vous devriez écrire vous-même, simplement au coût de la configuration.

Answer 2

Je m'attendrais à ce que chaque appel de service Web soit une requête/réponse. En cas d'erreur telle que le service est indisponible ou que les délais d'attente sont dépassés, je m'attendrais à ce qu'une exception soit levée.

Est-il donc possible d'encercler l'appel avec un bloc try catch?

Answer 3

Cela dépendra des détails du framework de services Web que vous utilisez. D'après ce que vous montrez, je ne serais pas surpris s'il n'y a pas de mécanisme pour détecter cela.

Considérez que généralement un service Web n'a même pas besoin d'utiliser un transport tel que HTTP, vous pourriez répondre via des files d'attente, ou même par e-mail. En général, en tant qu'implémentation serveur d'un simple service Web, vous ne pouvez pas être sûr que votre client ait vu la réponse. Que concluriez-vous si votre test fonctionnait? À l'instant où vous avez fait le test, il est là, une nano-seconde après avoir décidé de ne pas enregistrer, mais avant que vous soyez revenu, il est parti. Il n'y a pas de relation transactionnelle entre le client et le serveur dans le simple SOAP/HTTP.

Il existe des normes supplémentaires en matière de services Web pour traiter certaines de ces questions, mais généralement vous devez concevoir vos services Web en partant du principe que l'appelant pourrait ne pas voir la réponse. (peut-être que vous fournissez également des services d'état, ainsi un client peut se déconnecter puis revenir et demander "avez-vous traité la commande 345").

Merci de nous dire ce que vous souhaitez accomplir avec cet enregistrement, peut-être que quelqu'un a une approche de conception pour aider.

Answer 4

Le protocole HTTP n'a aucune spécification sur la manière dont le serveur peut vérifier la connexion avec le client. Le sens de IsClientConnected - vérifier s'il existe une requête "insatisfaite" pour générer HttpResponse. Et peut-être (je ne suis pas sûr) si le client supporte keep-connection-alive.

Pensez à l'architecture pull - où vous avez une méthode à sens unique, et un watch-dog du côté client pour vérifier périodiquement si la méthode est terminée.

Answer 5

Je pense que pour que IsClientConnected retourne false, la partie de votre code de service Web qui dit "//.. Faites les choses du service Web" devrait prendre plus de temps pour s'exécuter que le paramètre de délai d'attente du client. Vous pourriez probablement simuler cela en définissant le délai d'attente du client à 60 secondes et en mettant un Thread.Sleep(70000) dans votre code de service Web avant l'appel à IsClientConnected.

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

Je pense que vous pourriez obtenir un retour false de IsClientConnected si vous déconnectiez physiquement le client du réseau pendant que la méthode de service Web était encore dans la partie avant la vérification d'IsClientConnected, mais je suppose que ce n'est pas ce que vous voulez.