wake-up-neo.com

Offizielle Gründe für "Software verursacht Verbindungsabbruch: Socketschreibfehler"

In Anbetracht dieses Stack-Trace-Ausschnitts

Verursacht durch: Java.net.SocketException: Software verursachte Verbindungsabbruch: Socketschreibfehler 
beim Java.net.SocketOutputStream.socketWrite0 (Native Methode)

Ich habe versucht, folgende Fragen zu beantworten:

  1. Welcher Code löst diese Ausnahme aus? (JVM?/Tomcat?/Mein Code?)
  2. Wodurch wird diese Ausnahme ausgelöst?

Zu # 1:  

Die JVM-Quelle von Sun enthält diese genaue Meldung nicht, aber ich denke, der Text Software hat den Verbindungsabbruch verursacht: Socket-Schreibfehler stammt von der nativen Implementierung von SocketOutputStream:

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

zu # 2

Meine Vermutung ist, dass dies der Fall ist, wenn der Client die Verbindung abgebrochen hat, bevor er die vollständige Antwort erhalten hat (z. B. eine Anfrage gesendet, aber bevor er die vollständige Antwort erhalten hat, wurde er geschlossen/beendet/offline).

Fragen:

  1. Sind die obigen Annahmen korrekt (Nr. 1 und Nr. 2)?
  2. Kann dies von der Situation unterschieden werden: "Konnte aufgrund eines Netzwerkfehlers auf der Seite server nicht an den Client schreiben"? oder würde das die gleiche Fehlermeldung rendern?
  3. Und am wichtigsten: Gibt es ein offizielles Dokument (z. B. von Sun), aus dem das oben Gesagte hervorgeht?

Ich muss einen Beweis haben, dass diese Stack-Ablaufverfolgung der "Fehler" des Socket-Clients ist, und der Server hätte nichts dagegen tun können. (Außer das Auslösen der Ausnahme oder die Verwendung eines Nicht-Sun-JVM-SocketOutputStream, obwohl beide die Tatsache, dass der Client beendet wurde, nicht wirklich vermeiden).

137
Eran Medan

Dieser Fehler kann auftreten, wenn das lokale Netzwerk eine .__ abbricht. Verbindung, z. B. wenn WinSock eine bestehende Verbindung schließt nachdem die erneute Datenübertragung fehlgeschlagen ist (der Empfänger quittiert niemals die Daten, die auf einem Datenstrom-Socket gesendet wurden.).

Siehe diesen MSDN-Artikel . Siehe auch Einige Informationen zu 'Software-Verbindungsabbruch' .

49
user207421

Ich habe dies am häufigsten gesehen, wenn eine Unternehmensfirewall auf einer Workstation/einem Laptop in die Quere kommt und die Verbindung unterbrochen wird.

z.B. Ich habe einen Serverprozess und einen Clientprozess auf demselben Rechner. Der Server überwacht alle Schnittstellen (0.0.0.0) und der Client versucht, eine Verbindung zur öffentlichen/Home-Schnittstelle herzustellen (beachten Sie nicht die Loopback-Schnittstelle 127.0.0.1).

Wenn das Netzwerk der Maschine getrennt ist (z. B. WLAN), wird die Verbindung hergestellt. Wenn der Computer mit dem Unternehmensnetzwerk verbunden ist (direkt oder über VPN), wird die Verbindung hergestellt.

Wenn der Computer jedoch an ein öffentliches WLAN (oder ein Heimnetzwerk) angeschlossen ist, führt die Firewall dazu, dass die Verbindung unterbrochen wird. In dieser Situation funktioniert das Verbinden des Clients mit der Loopback-Schnittstelle einwandfrei, nicht jedoch mit der Home/Public-Schnittstelle.

Hoffe das hilft.

8
user2028913

Der Java.net.SocketException wird ausgelöst, wenn beim Erstellen oder Zugreifen auf ein Socket ein Fehler auftritt (z. B. TCP ). Dies kann normalerweise der Fall sein, wenn der Server die Verbindung abgebrochen hat (ohne sie ordnungsgemäß zu schließen), bevor Sie die vollständige Antwort erhalten. In den meisten Fällen kann dies entweder durch das Timeout-Problem verursacht werden (z. B. die Antwort dauert zu lange oder der Server ist mit den Anforderungen überlastet), oder der Client hat das SYN gesendet, er hat jedoch kein ACK (Bestätigung der Verbindungsbeendigung) erhalten. . Bei Timeout-Problemen können Sie den Timeout-Wert erhöhen.

Die Socket-Ausnahme enthält normalerweise die angegebene Detailmeldung zum Problem.

Beispiel für detaillierte Nachrichten:

  • Software verursacht Verbindungsabbruch: Recv fehlgeschlagen.

    Der Fehler zeigt an, dass versucht wurde, die Nachricht zu senden, und die Verbindung wurde von Ihrem Server abgebrochen. Wenn dies während der Verbindung zur Datenbank geschieht, kann dies mit der Verwendung von nicht kompatiblem Connector/J JDBC-Treiber zusammenhängen.

    Mögliche Lösung: Stellen Sie sicher, dass Sie in Ihrem CLASSPATH die richtigen Bibliotheken/Treiber installiert haben.

  • Software verursachte Verbindungsabbruch: Verbinden.

    Dies kann passieren, wenn ein Problem beim Herstellen der Verbindung mit der Fernbedienung besteht. Zum Beispiel weil Virenprüfer die Remote-Mail-Anfragen ablehnen .

    Mögliche Lösung: Überprüfen Sie den Virensuchdienst, ob er den Port für ausgehende Verbindungsanforderungen blockiert.

  • Software verursachte Verbindungsabbruch: Socketschreibfehler.

    Mögliche Lösung: Stellen Sie sicher, dass Sie die richtige Länge von Bytes in den Stream schreiben. Überprüfen Sie also, was Sie senden. Siehe diesen Thread .

  • Verbindung von Peer zurückgesetzt: Socketschreibfehler/Verbindung von Peer abgebrochen: Socketschreibfehler

    Die Anwendung hat nicht geprüft, ob auf der Serverseite eine Keep-Alive-Verbindung unterbrochen wurde.

    Mögliche Lösung: Stellen Sie sicher, dass der HttpClient nicht null ist, bevor Sie von der Verbindung lesen.E13222_01

  • Verbindung von Peer zurückgesetzt.

    Die Verbindung wurde vom Peer (Server) abgebrochen.

  • Verbindung zurücksetzen.

    Die Verbindung wurde entweder vom Client beendet oder vom Server-Ende der Verbindung aufgrund einer Anfrage mit der Anfrage geschlossen.

    Siehe: Was verursacht meine Java.net.SocketException: Verbindungsrücksetzung?

5
kenorb

Um zu beweisen, welche Komponente ausfällt, würde ich die TCP/IP-Kommunikation mit wireshark überwachen und feststellen, wer den Port tatsächlich schließt. Auch Timeouts könnten relevant sein.

4
stacker

Haben Sie den Tomcat-Quellcode und die JVM-Quelle überprüft? Das kann dir mehr helfen.

Ich denke, dein allgemeines Denken ist gut. Ich würde eine ConnectException in dem Szenario erwarten, das Sie nicht verbinden konnten. Das obige sieht sehr nach Client-basiert aus.

2
Brian Agnew

Für jeden, der einfache Client-Server-Programme verwendet und diesen Fehler erhält, handelt es sich um ein Problem mit nicht geschlossenen (oder früh zu geschlossenen) Eingabe- oder Ausgabeströmen.

2
PRO_gramista

Ich stand vor demselben Problem.
Häufig Diese Art von Fehler tritt auf, weil der Client seine Verbindung geschlossen hat und der Server immer noch versucht, auf diesem Client zu schreiben.
Stellen Sie also sicher, dass die Verbindung Ihres Clients geöffnet ist, bis der Server mit seinem Ausgabestrom fertig ist.
Und noch etwas, vergiss es nicht  Ein- und Ausgabestrom schließen.

Hoffe das hilft. 
Und wenn immer noch ein Problem als kurz vor Ihrem Problem hier im Detail.

1
Nirav Chhatrola

Geschlossene Verbindung in einem anderen Client

In meinem Fall war der Fehler:

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

Es wurde in Eclipse empfangen, während eine Java-Anwendung, die auf eine H2-Datenbank zugreift, debuggt wird. Die Fehlerquelle war, dass ich die Datenbank zunächst mit SQuirreL geöffnet hatte, um die Integrität manuell zu überprüfen. Ich habe das Flag verwendet, um mehrere Verbindungen zu derselben Datenbank zu ermöglichen (d. H. AUTO_SERVER=TRUE), sodass es keine Probleme gab, eine Verbindung von Java aus mit der Datenbank herzustellen.

Der Fehler trat auf, als nach einiger Zeit - es ist ein langer Java-Prozess - ich beschloss, SQuirreL zu schließen, um Ressourcen freizugeben. Es scheint, als ob SQuirreL die Instanz des DB-Servers war, die mit der SQuirreL-Verbindung heruntergefahren wurde.

Beim Neustart der Java-Anwendung wurde der Fehler nicht erneut angezeigt.

config

  • Windows 7
  • Eclipse Kepler
  • QUALITÄT 3.6
  • org.h2.Driver ver 1.4.192
0
manuelvigarcia

Dieser Fehler ist mir beim Testen meines Seifendienstes mit dem SoapUI-Client passiert. Im Grunde habe ich versucht, eine sehr große Nachricht (> 500kb) zu erhalten, und SoapUI hat die Verbindung durch Timeout geschlossen.

Auf SoapUI gehe zu:

Datei -> Einstellungen - Socket-Timeout (ms)

... und legen Sie einen großen Wert wie 180000 (3 Minuten) fest. Dies ist nicht die perfekte Lösung für Ihr Problem, da die Datei tatsächlich zu groß ist, aber zumindest haben Sie eine Antwort.

0
Marco