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

Question

J'obtiens l'erreur suivante en essayant de lire à partir d'un socket. Je fais un readInt() sur ce point InputStream et j'obtiens cette erreur. En parcourant la documentation, cela suggère que la partie client de la connexion a fermé la connexion. Dans ce scénario, je suis le serveur.

J'ai accès aux fichiers journaux du client et il ne ferme pas la connexion, et en fait ses fichiers journaux suggèrent que je ferme la connexion. Quelqu'un a-t-il une idée de la raison pour laquelle cela se produit ? Que faut-il vérifier d'autre ? Cela se produit-il lorsque des ressources locales atteignent des seuils ?

---

Je note cependant que j'ai la ligne suivante :

socket.setSoTimeout(10000);

juste avant le readInt() . Il y a une raison à cela (longue histoire), mais par curiosité, y a-t-il des circonstances dans lesquelles cela pourrait conduire à l'erreur indiquée ? J'ai le serveur en cours d'exécution dans mon IDE, et il se trouve que j'ai laissé mon IDE bloqué sur un point d'arrêt, et j'ai alors remarqué que les mêmes erreurs exactement ont commencé à apparaître dans mes propres journaux dans mon IDE.

Quoi qu'il en soit, je ne fais que le mentionner, en espérant qu'il ne s'agisse pas d'un hareng rouge :-(.

Answer 1

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 flux.

Answer 2

J'ai eu ce problème avec un système SOA écrit en Java. J'exécutais le client et le serveur sur des machines physiques différentes et ils ont fonctionné correctement pendant un long moment, puis ces réinitialisations de connexion désagréables sont apparues dans le journal du client, alors qu'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 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'erreur OutOfMemoryError dans le journal : la mémoire était juste rare, pas épuisée.

Answer 3

Vérifiez la version de Java de votre serveur. Cela m'est arrivé parce que mon Weblogic 10.3.6 était sur le JDK 1.7.0_75 qui était sur TLSv1. Le point final de repos que j'essayais de consommer fermait tout ce qui était en dessous de TLSv1.2.

Par défaut, Weblogic essayait de négocier le protocole partagé le plus fort. Voir les détails ici : Problèmes liés à la définition de la propriété système https.protocols pour les connexions HTTPS .

J'ai ajouté une journalisation SSL verbeuse pour identifier les TLS supportés. Cela indiquait que TLSv1 était utilisé pour la poignée de main.
-Djavax.net.debug=ssl:handshake:verbose:keymanager:trustmanager -Djava.security.debug=access:stack

J'ai résolu ce problème en intégrant cette fonctionnalité à notre produit compatible avec le JDK8, qui utilise par défaut TLSv1.2. Pour ceux qui sont limités à JDK7, j'ai également testé avec succès une solution de contournement pour Java 7 en passant à TLSv1.2. J'ai utilisé cette réponse : Comment activer TLS 1.2 dans Java 7 ?

Answer 4

J'ai également rencontré ce problème avec un programme Java qui essayait d'envoyer une commande sur un serveur via SSH. Le problème venait de la machine qui exécutait le code Java. Elle n'avait pas la permission de se connecter au serveur distant. La méthode write() s'en sortait bien, mais la méthode read() provoquait une java.net.SocketException : Connection reset. J'ai résolu ce problème en ajoutant la clé SSH du client aux clés connues du serveur distant.

Answer 5

Dans mon cas, c'était DNS problem .
J'ai mis host file l'IP résolue et tout fonctionne bien. Bien sûr, ce n'est pas une solution permanente, mais cela me donne le temps de résoudre le problème des DNS.