java.net.SocketException: réinitialisation de la connexion

Il y a plusieurs causes possibles.

1. L’autre extrémité a délibérément réinitialisé la connexion, d’une manière que je ne documenterai pas ici. Cela est rare, et généralement incorrect, pour le logiciel d’application, mais ce n’est pas inconnu pour les logiciels commerciaux.

2. Plus généralement, cela est dû à l’écriture sur une connexion que l’autre extrémité a déjà fermée normalement. En d’autres termes, une erreur de protocole d’application.

3. Cela peut également être provoqué par la fermeture d’un socket lorsqu’il y a des données non lues dans le tampon de réception du socket.

4. Sous Windows, «l’abandon de connexion provoqué par un logiciel», qui n’est pas la même chose que la «réinitialisation de la connexion», est dû à des problèmes de réseau envoyés de votre côté. Il existe un article de la base de connaissances Microsoft à ce sujet.

La réinitialisation de la connexion signifie simplement qu’un message TCP RST a été reçu. Cela se produit lorsque votre homologue reçoit des données qu’il ne peut pas traiter, et il peut y avoir plusieurs raisons à cela.

Le plus simple est lorsque vous fermez le socket, puis écrivez plus de données sur le stream de sortie. En fermant le socket, vous avez dit à votre homologue que vous aviez fini de parler et que cela pouvait faire oublier votre connexion. Lorsque vous envoyez de plus en plus de données sur ce stream, le pair le refuse avec un RST pour vous informer qu’il n’écoute pas.

Dans d’autres cas, un pare-feu intermédiaire ou même l’hôte distant lui-même pourrait “oublier” votre connexion TCP. Cela peut se produire si vous n’envoyez pas de données pendant une longue période (2 heures est un délai d’attente courant) ou parce que l’homologue a été redémarré et a perdu ses informations sur les connexions actives. L’envoi de données sur l’une de ces connexions obsolètes provoquera également une TVD.

Mise à jour en réponse à des informations supplémentaires:

Jetez un coup d’œil à votre gestion de l’ SocketTimeoutException . Cette exception est déclenchée si le délai d’attente configuré est dépassé alors qu’il est bloqué sur une opération de socket. L’état du socket lui-même n’est pas modifié lorsque cette exception est levée, mais si votre gestionnaire d’exceptions ferme le socket et tente ensuite d’y écrire, vous serez dans une condition de réinitialisation de la connexion. setSoTimeout() pour but de vous donner un moyen propre de sortir d’une opération read() qui pourrait être bloquée pour toujours, sans faire de choses sales comme fermer le socket d’un autre thread.

Chaque fois que j’ai eu des problèmes étranges comme celui-ci, je m’assieds habituellement avec un outil tel que WireShark et je regarde les données brutes transmises. Vous pourriez être surpris de voir les choses se déconnecter et vous ne serez averti que lorsque vous essayez de lire.

Embarrassant de le dire, mais quand j’ai eu ce problème, c’était simplement une erreur que je fermais la connexion avant de lire toutes les données. Dans les cas où de petites chaînes étaient renvoyées, cela fonctionnait, mais cela était probablement dû à la mise en mémoire tampon de toute la réponse, avant de la fermer.

En cas de retour de plus grandes quantités de texte, l’exception a été levée, puisqu’un tampon revenait.

Vous pourriez vérifier cette omission. Rappelez-vous que l’ouverture d’une URL est comme un fichier, veillez à la fermer (libérez la connexion) une fois qu’elle a été entièrement lue.

Vous devez inspecter toute la trace très attentivement,

J’ai une application de socket serveur et java.net.SocketException: Connection reset corrigé un cas java.net.SocketException: Connection reset .

Dans mon cas, cela se produit lors de la lecture d’un object Socket clientSocket qui est fermé sa connexion pour une raison quelconque. (Réseau perdu, pare-feu ou plantage de l’application ou fermeture prévue)

En fait, j’étais en train de rétablir la connexion quand j’ai eu une erreur lors de la lecture de cet object Socket.

 Socket clientSocket = ServerSocket.accept(); is = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); int readed = is.read(); // WHERE ERROR STARTS !!! 

La chose intéressante est for my JAVA Socket si un client se connecte à mon ServerSocket et ferme sa connexion sans rien envoyer is.read() appelle lui-même de manière récursive. à partir d’une connexion fermée. Si vous utilisez quelque chose comme ci-dessous pour une opération de lecture;

 while(true) { Receive(); } 

Ensuite, vous obtenez un stackTrace quelque chose comme ci-dessous sur et sur

 java.net.SocketException: Socket is closed at java.net.ServerSocket.accept(ServerSocket.java:494) 

Ce que j’ai fait, c’est simplement fermer ServerSocket et renouveler ma connexion et attendre d’autres connexions client entrantes

 Ssortingng Receive() throws Exception { try { int readed = is.read(); .... }catch(Exception e) { tryReConnect(); logit(); //etc } //... } 

Cela rétablit ma connexion pour les emplacements de socket client inconnus

 private void tryReConnect() { try { ServerSocket.close(); //empty my old lost connection and let it get by garbage col. immediately clientSocket=null; System.gc(); //Wait a new client Socket connection and address this to my local variable clientSocket= ServerSocket.accept(); // Waiting for another Connection System.out.println("Connection established..."); }catch (Exception e) { Ssortingng message="ReConnect not successful "+e.getMessage(); logit();//etc... } } 

Je ne pouvais pas trouver un autre moyen parce que, comme vous le voyez dans l’image ci-dessous, vous ne pouvez pas comprendre si la connexion est perdue ou non sans try and catch , parce que tout semble correct. J’ai eu cet instantané pendant que je devais Connection reset permanence.

J’ai eu la même erreur. J’ai trouvé la solution au problème maintenant. Le problème était que le programme client se terminait avant que le serveur ne lise les stream.

J’ai eu ce problème avec un système SOA écrit en Java. J’exécutais à la fois le client et le serveur sur différentes machines physiques et ils fonctionnaient correctement pendant une longue période, puis ces mauvaises restaurations de connexion apparaissaient dans le journal du client et le journal du serveur n’avait rien d’étonnant. Le redémarrage du client et du serveur n’a pas résolu le problème. Enfin, nous avons découvert que le tas du côté serveur était plutôt plein, nous avons donc augmenté la mémoire disponible pour la JVM: problème résolu! Notez qu’il n’y avait pas d’OutOfMemoryError dans le journal: la mémoire était juste rare, pas épuisée.

J’ai aussi eu ce problème avec un programme Java essayant d’envoyer une commande sur un serveur via SSH. Le problème était avec la machine exécutant le code Java. Il n’était pas autorisé à se connecter au serveur distant. La méthode write () se passait bien, mais la méthode read () lançait une exception java.net.SocketException: la réinitialisation de la connexion. J’ai corrigé ce problème en ajoutant la clé SSH du client aux clés connues du serveur distant.