Raisons officielles pour “Abandon de connexion causé par le logiciel: erreur d’écriture de socket”

Étant donné cet extrait de trace de stack

Causé par: java.net.SocketException: Abandon de connexion causé par le logiciel: erreur d’écriture de socket
at java.net.SocketOutputStream.socketWrite0 (méthode native)

J’ai essayé de répondre aux questions suivantes:

  1. Quel code lance cette exception? (JVM? / Tomcat? / Mon code?)
  2. Qu’est-ce qui cause cette exception?

En ce qui concerne # 1:

La source JVM de Sun ne contient pas ce message exact, mais je pense que le texte du logiciel a provoqué l’abandon de la connexion: l’erreur d’écriture de socket provient de l’implémentation native de SocketOutputStream :

 private native void socketWrite0(FileDescriptor fd, byte[] b, int off, int len) throws IOException; 

En ce qui concerne # 2

Je suppose que cela est causé lorsque le client a mis fin à la connexion, avant d’obtenir la réponse complète (par exemple, une demande envoyée, mais avant d’obtenir la réponse complète, elle est fermée / terminée / hors ligne).

Des questions:

  1. Les hypothèses ci-dessus sont-elles correctes (# 1 et # 2)?
  2. Cela peut-il être différent de la situation: “ne pouvait pas écrire sur le client, en raison d’une erreur de réseau côté serveur “? ou serait-ce rendre le même message d’erreur?
  3. Et le plus important: existe-t-il un document officiel (par exemple de Sun) indiquant ce qui précède?

Je dois avoir une preuve que cette trace de stack est la “faute” du client de socket, et que le serveur n’a rien pu faire pour l’éviter. (sauf capture de l’exception ou utilisation d’un SocketOutputStream autre que Sun JVM, bien que les deux n’évitent pas le fait que le client soit arrêté)

“Cette erreur peut se produire lorsque le système de réseau local interrompt une connexion, par exemple lorsque WinSock ferme une connexion établie après que la retransmission des données échoue (le récepteur n’accuse jamais les données envoyées sur un socket de stream de données).” Voir cet article MSDN . Voir aussi Quelques informations sur “Abandon de connexion causé par un logiciel” .

Je l’ai vu le plus souvent quand un pare-feu d’entreprise sur un poste de travail / ordinateur portable entrave la communication.

par exemple. J’ai un processus serveur et un processus client sur la même machine. Le serveur écoute sur toutes les interfaces (0.0.0.0) et le client tente une connexion à l’interface public / home (notez que l’interface de bouclage 127.0.0.1).

Si la machine a son réseau déconnecté (par exemple, wifi éteint), alors la connexion est formée. Si la machine est connectée au réseau d’entreprise (directement ou vpn), la connexion est établie.

Cependant, si la machine est connectée à un réseau wifi public (ou réseau domestique), le pare-feu déclenche une connexion qui tue. Dans cette situation, la connexion du client à l’interface de bouclage fonctionne correctement, mais pas à l’interface home / public.

J’espère que cela t’aides.

Pour prouver que le composant échoue, je surveillerais la communication TCP / IP à l’aide de wireshark et je verrais qui ferme effectivement le port.

java.net.SocketException est levée en cas d’erreur lors de la création ou de l’access à un socket (tel que TCP ). Cela peut généralement être causé lorsque le serveur a mis fin à la connexion (sans la fermer correctement), donc avant d’obtenir la réponse complète. Dans la plupart des cas, cela peut être dû au problème de délai d’attente (par exemple, la réponse prend trop de temps ou le serveur est surchargé avec les requêtes) ou le client a envoyé le SYN, mais il n’a pas reçu ACK . Pour les problèmes de délai d’attente, vous pouvez envisager d’augmenter la valeur du délai d’attente.

L’exception Socket est généralement accompagnée du message de détail spécifié sur le problème.

Exemple de messages détaillés:

  • Le logiciel a causé une interruption de la connexion: recv a échoué.

    L’erreur indique une tentative d’envoi du message et la connexion a été interrompue par votre serveur. Si cela s’est produit lors de la connexion à la firebase database, cela peut être lié à l’utilisation d’un pilote JDBC Connector / J non compatible .

    Solution possible: assurez-vous que vos bibliothèques / pilotes sont corrects dans votre CLASSPATH.

  • Abandon de la connexion causée par le logiciel: connect.

    Cela peut se produire en cas de problème de connexion à la télécommande. Par exemple, le vérificateur de virus a rejeté les demandes de courrier à distance .

    Solution possible: Vérifiez si le service de scan antivirus bloque le port pour les demandes sortantes de connexion.

  • Abandon de connexion causé par le logiciel: erreur d’écriture de socket.

    Solution possible: Assurez-vous d’écrire la longueur correcte d’octets dans le stream. Vérifiez donc ce que vous envoyez. Voir ce fil

  • Connexion réinitialisée par un homologue: erreur d’écriture de socket / connexion interrompue par un homologue: erreur d’écriture de socket

    L’application n’a pas vérifié si la connexion persistante avait expiré du côté serveur.

    Solution possible: Assurez-vous que HttpClient est non nul avant de lire la connexion. E13222_01

  • Réinitialisation de la connexion par paire.

    La connexion a été interrompue par le pair (serveur).

  • Connexion réinitialisée.

    La connexion a été soit interrompue par le client, soit fermée par la fin du serveur en raison d’une demande avec la demande.

    Voir: Qu’est-ce qui cause mon java.net.SocketException: la réinitialisation de la connexion?

Avez-vous vérifié le code source Tomcat et la source JVM? Cela peut vous donner plus d’aide.

Je pense que votre pensée générale est bonne. Je m’attendrais à une ConnectException dans le scénario que vous ne pouviez pas vous connecter. Ce qui précède ressemble beaucoup à ce qui est axé sur le client.

Pour quiconque utilise des programmes simples de Client Server et reçoit cette erreur, il s’agit d’un problème de stream d’entrée ou de sortie non fermés (ou fermés au début).

Je faisais face au même problème.
Communément Ce type d’erreur se produit car le client a fermé sa connexion et le serveur tente toujours d’écrire sur ce client.
Assurez-vous donc que la connexion de votre client est ouverte jusqu’à ce que le serveur utilise son stream de sortie.
Et encore une chose, Don`t a oublié de fermer les stream d’entrée et de sortie.

J’espère que cela t’aides.
Et si vous êtes toujours confronté à un problème, rédigez votre problème ici en détails.

Cette erreur m’est arrivée lors du test de mon service de soap avec le client SoapUI, en gros j’essayais d’obtenir un très gros message (> 500kb) et SoapUI fermait la connexion par timeout.

Sur SoapUI, allez à:

Fichier -> Préférences – Socket Timeout (ms)

… et mettez une grande valeur, telle que 180000 (3 minutes), ce ne sera pas la solution idéale pour votre problème car le fichier est trop volumineux, mais au moins vous aurez une réponse.

Connexion fermée dans un autre client

Dans mon cas, l’erreur était la suivante:

 java.net.SocketException: Software caused connection abort: recv failed 

Il a été reçu en éclipse lors du débogage d’une application Java accédant à une firebase database H2. La source de l’erreur était que j’avais initialement ouvert la firebase database avec SQuirreL pour vérifier l’intégrité manuellement. J’ai utilisé le drapeau pour activer plusieurs connexions vers la même firebase database (c.-à-d. AUTO_SERVER=TRUE ), donc il n’y avait pas de problème de connexion à la firebase database depuis Java.

L’erreur est apparue lorsque, après un certain temps, il s’agit d’un long processus java, j’ai décidé de fermer SQuirreL pour libérer des ressources. Il semble que SQuirreL soit celui qui “possède” l’instance du serveur de firebase database et qu’il a été arrêté avec la connexion SQuirreL.

Le redémarrage de l’application Java n’a plus généré l’erreur.

config

  • Windows 7
  • Eclipse Kepler
  • SQuirreL 3.6
  • org.h2.Driver ver 1.4.192

Mon serveur lançait cette exception au cours des 2 derniers jours et je l’ai résolu en déplaçant la fonction de déconnexion avec:

 outputStream.close(); inputStream.close(); Client.close(); 

À la fin du fil de liste. si ça va aider quelqu’un.

Dans la situation décrite ci-dessous, le côté client lancera une telle exception:

Le serveur est invité à authentifier le certificate client, mais le client fournit un certificate dont l’utilisation de clé étendue ne prend pas en charge l’authentification client, de sorte que le serveur n’accepte pas le certificate du client, puis ferme la connexion.

Je faisais face au même problème avec wireMock en moquant les appels API restants. Auparavant, je définissais le serveur comme ceci:

 WireMockServer wireMockServer = null; 

Mais il faut le définir comme ci-dessous:

 @Rule public WireMockRule wireMockRule = new WireMockRule(8089);