10
votes

Détecter la déconnexion du client dans le servlet Tomcat?

Comment puis-je détecter que le côté client d'une demande de servlet Tomcat a été déconnecté? J'ai lu que je devrais faire une réponse.GetOutoutPutStream (). Imprimer (), puis une réponse.getoutoutPutStream (). Flush () et attrapez une inception IoException, mais y a-t-il une façon de le détecter sans écrire de données? < / p>

edit :

Le servlet envoie un flux de données qui ne se termine pas nécessairement, mais ne dispose pas nécessairement de données qui le coulent (c'est un flux d'événements en temps réel). J'ai besoin de détecter réellement lorsque le client déconnecte parce que j'ai un peu de nettoyage que je dois faire à ce stade (ressources à la libération, etcetera). Si j'ai le HTTPServletReQuest disponible, il tentera de lire à partir de celui-ci lancer une IOException si le client déconnecte?


0 commentaires

3 Réponses :


9
votes

Y a-t-il une façon de détecter cela Sans écrire des données?

Non, car il n'y a pas de moyen dans TCP / IP pour la détecter sans écrire de données.

Ne vous inquiétez pas pour ça. Terminez simplement les actions de la demande et écrivez la réponse. Si le client a disparu, cela provoquera une inexception IoException: la réinitialisation de la connexion, qui sera jetée dans le récipient de servlet. Rien de ce que vous avez à faire à ce sujet.


9 commentaires

"Rien que vous devez faire à ce sujet." - et rien que vous puissiez faire à ce sujet.


J'ai édité la question de clarifier. J'aimerais ne pas avoir à envoyer des données parasites au client à moins que je ne l'appelle absolument.


Vous ne le ferez pas. Vous obtiendrez une exception à la place et le conteneur traitera de cela.


non car il n'y a pas de moyen dans TCP / IP pour la détecter sans écrire de données. - Qu'en est-il de RST paquet?


@Pavelhoral La seule façon de provoquer un paquet RST à envoyer en réponse est d'écrire des données.


@EJP: Je pense que la question n'est pas claire. Dans ma compréhension, un Disconnect arrive. lorsque l'application client se termine. Dans un tel cas, le système d'exploitation enverra un paquet RST sur le serveur qui pourrait déclencher une notification. Toutefois, si l'ordinateur client est déconnecté (j'appellerais une interruption de réseau), il n'y aura pas de paquet RST bien sûr. Vous répondez seulement couvre la deuxième variante.


La possibilité de "compléter la demande" est dans de nombreux cas non bien. Par exemple, dans le système, je soutiens, certaines requêtes d'utilisateurs peuvent être faites, mais elles prennent très longtemps de temps à compléter sans écrire de données. L'utilisateur pourrait tout simplement être déconnecté la demande est toujours traitée jusqu'à la fin, ce qui, dans certains cas, ces types de demandes occupent toutes les connexions Tomcat. Est-ce un moyen d'éviter cela?


@Gordonliang Ce n'est pas une "option". C'est le seul choix que vous avez.


@Robert Il y aura une réinitialisation lorsque vous continuez à envoyer des données. J'ai déjà dit ça.



5
votes

j'ai besoin de détecter réellement lorsque le client déconnecte parce que j'ai un peu de nettoyage que je dois faire à ce stade (ressources à la libération, etcetera).

là le bloc enfin est pour. Il sera exécuté indépendamment du résultat. E.g. xxx

Si j'ai le HTTPServletReQuest disponible, j'essayera de lire à partir de celui-ci lancer une ioException si le client déconnecte?

dépend de la façon dont vous en lit et de la quantité de corps de demande déjà dans la mémoire du serveur. Dans le cas de la forme normale des demandes codées, chaque fois que vous appelez getParameter () au préalable, il sera généralement complètement analysé et stocké dans la mémoire du serveur. Appeler le getinputtream () ne sera pas utile du tout. Mieux vaut le faire sur la réponse à la place.


2 commentaires

Le corps de la demande n'est pas dans la mémoire du serveur, jusqu'à ce que vous le lisiez (à l'aide d'un flux d'entrée de demande ou d'appeler getParameter () en cas de publication avec application / x-www-form-urlencoded). Le corps de la demande peut être de n'importe quelle taille, le serveur ne peut pas simplement le mettre en cache en mémoire.


@Peter: J'ai éliminé l'ambiguïté.



3
votes

Avez-vous essayé de rincer le tampon de la réponse: réponse.flushbuffer (); Semble lancer une impression IoException lorsque le client s'est déconnecté.


1 commentaires

Il ne lancera pas à moins d'avoir vraiment quelque chose à envoyer au client.