java.net.Exception socketexception: Connection reset

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. Il est rare, et généralement incorrect, pour les logiciels d'application de le faire, mais il n'est pas inconnu pour les logiciels commerciaux.

2. Plus généralement, cela est causé par 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. Il peut également être causé par fermeture d'un socket lorsqu'il y a des données non lues dans le tampon de réception du socket.

4. Sous Windows, "le logiciel a provoqué l'abandon de la connexion", ce qui n'est pas le même que "réinitialisation de la connexion", est causé par des problèmes de réseau envoyés de votre côté. Il y a un article de la base de connaissances Microsoft à ce sujet.

La réinitialisation de la connexion signifie simplement qu'un 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 diverses raisons à cela.

Le plus simple est lorsque vous fermez le socket, puis écrivez plus de données sur le flux de sortie. En fermant le socket, vous avez dit à votre homologue que vous avez fini de parler, et il peut oublier votre connexion. Lorsque vous envoyez plus de données sur ce flux de toute façon, le pair le rejette avec un RST pour vous faire savoir que ce n'est pas le cas écoute.

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 aucune donnée pendant une longue période (2 heures est un délai d'attente courant), ou parce que le pair a été redémarré et a perdu ses informations sur les connexions actives. L'envoi de données sur l'une de ces connexions défuntes provoquera également un RST.

mise à Jour en réponse à des informations supplémentaires:

Regardez de près votre manipulation du SocketTimeoutException. Cette exception est levée si le délai d'attente configuré est dépassé lors d'un blocage sur une opération 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, puis essaie d'y écrire, vous serez dans une condition de réinitialisation de connexion. setSoTimeout() est destiné à vous donner un moyen propre de sortir d'une opération read() qui pourrait sinon bloquer pour toujours, sans faire de choses sales comme fermer le socket d'un autre fil.

Chaque fois que j'ai eu des problèmes étranges comme celui-ci, je m'assois généralement avec un outil comme WireShark et regarde les données brutes transmises d'avant en arrière. Vous pourriez être surpris où les choses sont déconnectées, et vous êtes seulement notifié 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 sont retournées, cela a fonctionné, mais c'était probablement dû au fait que toute la réponse a été mise en mémoire tampon, avant que je ne la ferme.

Dans les cas où des quantités de texte plus longues étaient renvoyées, l'exception était levée, car plus d'un tampon revenait.

Vous pouvez vérifier cet oubli. N'oubliez pas d'ouvrir une URL est comme un fichier, assurez-vous de le fermer (relâchez la connexion) une fois qu'il a été entièrement lu.

Vous devriez inspecter la trace complète très soigneusement,

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

Dans mon cas, cela se produit lors de la lecture d'un objet clientSocket Socket qui est fermé sa connexion pour une raison quelconque. (Perte du réseau, blocage du pare-feu ou de l'application ou fermeture prévue)

En fait, je rétablissais la connexion lorsque j'ai eu une erreur lors de la lecture de cet objet 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 le client se connecte à mon ServerSocket et ferme sa connexion sans rien envoyer is.read() s'appelle lui-même recursively.It semble en raison d'être dans une boucle while infinie pour lire à partir de ce socket, vous essayez de lire à partir d'une connexion fermée. Si vous utilisez quelque chose comme ci-dessous pour l'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 un autre client entrant connexions

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


//...
}

Cela rétablit ma connexion pour les pertes de socket client inconnu

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) {
                String message="ReConnect not successful "+e.getMessage();
                logit();//etc...
            }
        }

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

J'ai eu le même message d'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 flux.

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 ont bien fonctionné pendant longtemps, puis ces réinitialisations de connexion désagréables sont apparues dans le journal du client et il n'y avait rien d'étrange dans le journal du serveur. Le redémarrage du client et du serveur n'a pas résolu le problème. Finalement nous avons découvert que le tas côté serveur était plutôt plein donc nous avons augmenté la mémoire disponible pour la JVM: problème résolu! Note qu'il n'y avait pas OutOfMemoryError dans le journal: la mémoire était juste rare, pas épuisée.

J'ai également 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'avait pas l'autorisation de se connecter au serveur distant. La méthode write() se portait bien, mais la méthode read () lançait une java.net.SocketException: Connection reset. J'ai résolu ce problème avec l'ajout de la clé SSH client aux clés connues du serveur distant.