Raisons officielles pour "Abandon de la connexion causé par un logiciel: erreur d'écriture de la socket"
Étant donné cet extrait de trace de pile
Causé par: Java.net.SocketException: Le logiciel a provoqué la déconnexion: erreur d'écriture de socket
à Java.net.SocketOutputStream.socketWrite0 (Méthode native )
J'ai essayé de répondre aux questions suivantes:
- Quel code lance cette exception? (JVM?/Tomcat?/Mon code?)
- Qu'est-ce qui provoque cette exception?
Concernant le n ° 1:
La source JVM de Sun ne contient pas ce message exact, mais je pense que le texte Logiciel a provoqué une interruption de 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;
Concernant # 2
Je suppose que cela est dû au fait que le client a mis fin à la connexion, avant d'obtenir la réponse complète (par exemple, une demande, mais avant d'obtenir la réponse complète, elle a été fermée/fermée/hors ligne).
Des questions:
- Les hypothèses ci-dessus sont-elles correctes (n ° 1 et n ° 2)?
- Est-ce que ceci peut être différencié de la situation: "impossible d'écrire sur le client, à cause d'une erreur réseau du côté serveur"? ou est-ce que cela rendrait le même message d'erreur?
- Et le plus important: Existe-t-il un document officiel (par exemple de Sun) indiquant ce qui précède?
J'ai besoin de prouver que cette trace de pile est la "faute" du client du socket, et le serveur n'a rien pu faire pour l'éviter. (à l'exception de la capture de l'exception ou de l'utilisation d'un flux SocketOutputStream autre que JVM de Sun, bien que les deux n'évitent pas vraiment le fait que le client a pris fin)
Cette erreur peut se produire lorsque le système de réseau local abandonne un connexion, par exemple lorsque WinSock ferme une connexion établie après l'échec de la retransmission des données (le destinataire ne reconnaît jamais les données envoyées sur un socket datastream).
Voir cet article MSDN . Voir aussi Quelques informations sur "Abandon de la connexion en raison d'un logiciel" .
C'est ce que j'ai vu le plus souvent lorsqu'un pare-feu d'entreprise sur un poste de travail/un ordinateur portable entrave le processus, il tue la connexion.
par exemple. J'ai un processus serveur et un processus client sur le même ordinateur. Le serveur est à l'écoute sur toutes les interfaces (0.0.0.0) et le client tente une connexion à l'interface publique/domestique (notez l'interface 127.0.0.1).
Si le réseau de la machine est déconnecté (par exemple, le wifi est désactivé), la connexion est établie. Si la machine est connectée au réseau d'entreprise (directement ou par vpn), la connexion est établie.
Toutefois, si la machine est connectée à un réseau wifi public (ou à un réseau domestique), le pare-feu déclenche la connexion. Dans ce cas, la connexion du client à l'interface de bouclage fonctionne correctement, mais pas à l'interface home/publique.
J'espère que cela t'aides.
Le Java.net.SocketException est renvoyé en cas d'erreur lors de la création ou de l'accès à un socket (tel que TCP ). Cela peut généralement se produire 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é de requêtes), ou le client a envoyé le SYN, mais il n'a pas reçu d'accusé de réception (accusé de réception de la connexion). . Pour les problèmes de délai d'attente, vous pouvez augmenter la valeur du délai d'attente.
L'exception de socket vient généralement avec le message de détail spécifié concernant le problème.
Exemple de messages détaillés:
Le logiciel a provoqué une interruption de la connexion: échec de recv.
L'erreur indique une tentative d'envoi du message et la connexion a été interrompue par votre serveur. Si cela se produit lors de la connexion à la base de données, cela peut être lié à l’utilisation de pilote non compatible Connector/J JDBC .
Solution possible: Assurez-vous que vous avez les bibliothèques/pilotes appropriés dans votre CLASSPATH.
Abandon de la connexion causé par le logiciel: connectez-vous.
Cela peut arriver en cas de problème de connexion à la télécommande. Par exemple en raison du refus du vérificateur de virus pour les demandes de courrier à distance .
Solution possible: vérifiez que le service d’analyse antivirus bloque le port des demandes de connexion sortantes.
Abandon de la connexion causé par le logiciel: erreur d'écriture du socket.
Solution possible: Assurez-vous que vous écrivez la longueur correcte d'octets dans le flux. Alors vérifiez bien ce que vous envoyez. Voir ce thread .
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 été dépassée côté serveur.
Solution possible: Assurez-vous que HttpClient est non-nul avant de lire à partir de la connexion.E13222_01
Réinitialisation de la connexion par paire.
La connexion a été terminée par l'homologue (serveur).
Connexion réinitialisée.
La connexion a été interrompue par le client ou fermée par l'extrémité serveur de la connexion en raison d'une requête avec la requête.
Voir: Quelle est la cause de mon Java.net.SocketException: Connection reset?
Pour prouver quel composant ne fonctionne pas, je surveillerais la communication TCP/IP à l’aide de wirehark et jetterai un œil à la personne qui ferme effectivement le port. Les délais d’expiration pourraient également être pertinents.
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 où vous ne pourriez pas vous connecter. Ce qui est décrit ci-dessus semble très axé sur le client.
Pour ceux qui utilisent de simples programmes Client Server et obtiennent cette erreur, il s’agit d’un problème de flux 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 que le serveur tente toujours d'écrire sur ce client.
Assurez-vous que votre client a sa connexion ouverte jusqu'au serveur avec son flux de sortie.
Et encore une chose, n’oubliez pas de fermer le flux d'entrée et de sortie.
J'espère que cela t'aides.
Et si le problème persiste, résumez votre problème ici en détail.
Connexion fermée dans un autre client
Dans mon cas, l'erreur était:
Java.net.SocketException: Software caused connection abort: recv failed
Il a été reçu dans Eclipse lors du débogage d'une application Java accédant à une base de données H2. L'erreur était due au fait que j'avais initialement ouvert la base de données avec SQuirreL pour vérifier manuellement l'intégrité. J'ai utilisé l'indicateur pour activer plusieurs connexions à la même base de données (c'est-à-dire AUTO_SERVER=TRUE). Il n'y a donc pas eu de problème de connexion à la base de données à partir de Java.
L'erreur est apparue quand, après un certain temps - c'est 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 base de données et qu'il a été arrêté avec la connexion SQuirreL.
Le redémarrage de l'application Java n'a pas généré l'erreur à nouveau.
config
- Windows 7
- Eclipse Kepler
- SQuirreL 3.6
- org.h2.Driver ver 1.4.192
Cette erreur m'est arrivée lors du test de mon service soap avec le client SoapUI. J'essayais en gros de recevoir un très gros message (> 500 Ko) et SoapUI a mis fin à la connexion.
Sur SoapUI, allez à:
Fichier -> Préférences - Socket Timeout (ms)
... et mettez une valeur importante, telle que 180000 (3 minutes), ce ne sera pas la solution idéale à votre problème, car le fichier est trop volumineux, mais vous aurez au moins une réponse.