it-swarm-eu.dev

java.net.SocketException: Verbindung zurückgesetzt

Beim Versuch, von einem Socket zu lesen, wird die folgende Fehlermeldung angezeigt. Ich mache eine readInt() auf diesem InputStream, und ich erhalte diesen Fehler. In der Dokumentation wird darauf hingewiesen, dass der Client-Teil der Verbindung die Verbindung geschlossen hat. In diesem Szenario bin ich der Server.

Ich habe Zugriff auf die Client-Protokolldateien, und die Verbindung wird nicht geschlossen. Die Protokolldateien deuten darauf hin, dass die Verbindung geschlossen wird. Hat jemand eine Idee, warum das passiert? Was gibt es sonst noch zu prüfen? Tritt dies auf, wenn es lokale Ressourcen gibt, die möglicherweise Schwellenwerte erreichen?


Ich stelle fest, dass ich die folgende Zeile habe:

socket.setSoTimeout(10000);

kurz vor der readInt(). Es gibt einen Grund dafür (lange Geschichte), aber nur neugierig, gibt es Umstände, unter denen dies zu dem angezeigten Fehler führen könnte? Ich habe den Server in meiner IDE ausgeführt, und ich habe meinen IDE auf einem Haltepunkt festgefahren, und dann habe ich festgestellt, dass genau dieselben Fehler in meinen eigenen Protokollen in meiner IDE erscheinen.

Wie auch immer, wenn ich es nur erwähne, hoffentlich kein roter Hering. :-(

109
Darryl

Es gibt mehrere mögliche Ursachen.

  1. Das andere Ende hat die Verbindung absichtlich auf eine Weise zurückgesetzt, die ich hier nicht dokumentieren werde. Es ist selten und im Allgemeinen falsch, dass Anwendungssoftware dies ausführt, bei kommerzieller Software ist dies jedoch nicht unbekannt.

  2. Häufiger wird es durch das Schreiben in eine Verbindung verursacht, dass das andere Ende bereits normal geschlossen wurde. Mit anderen Worten, ein Anwendungsprotokollfehler.

  3. Dies kann auch durch Schließen eines Sockets verursacht werden, wenn sich ungelesene Daten im Socket-Empfangspuffer befinden.

  4. In Windows wird der durch Software verursachte Verbindungsabbruch, der nicht mit dem Zurücksetzen der Verbindung identisch ist, durch Netzwerkprobleme verursacht, die von Ihrem Ende gesendet werden. Hierzu gibt es einen Microsoft Knowledge Base-Artikel.

105
user207421

Das Zurücksetzen der Verbindung bedeutet einfach, dass eine TCP RST empfangen wurde. Dies geschieht, wenn Ihr Peer Daten empfängt, die er nicht verarbeiten kann, und dies kann verschiedene Gründe haben.

Am einfachsten ist es, wenn Sie den Socket schließen und dann weitere Daten in den Ausgabestream schreiben. Durch Schließen des Sockets haben Sie Ihrem Kollegen mitgeteilt, dass Sie mit dem Sprechen fertig sind, und er kann Ihre Verbindung vergessen. Wenn Sie ohnehin mehr Daten auf diesem Stream senden, weist der Peer diese mit einem RST zurück, um Sie darauf hinzuweisen, dass der Stream nicht empfangsbereit ist.

In anderen Fällen "vergisst" eine zwischengeschaltete Firewall oder sogar der Remote - Host möglicherweise Ihre TCP) - Verbindung. Dies kann passieren, wenn Sie längere Zeit keine Daten senden (dies sind 2 Stunden) (Ein häufiges Zeitlimit) oder weil der Peer neu gestartet wurde und seine Informationen zu aktiven Verbindungen verloren hat.Das Senden von Daten zu einer dieser unterbrochenen Verbindungen führt ebenfalls zu einer RST.


pdate als Antwort auf zusätzliche Informationen:

Sehen Sie sich Ihren Umgang mit SocketTimeoutException genau an. Diese Ausnahme wird ausgelöst, wenn das konfigurierte Zeitlimit überschritten wird, während ein Socket-Vorgang blockiert ist. Der Status des Sockets selbst wird nicht geändert, wenn diese Ausnahme ausgelöst wird. Wenn jedoch Ihr Ausnahmehandler den Socket schließt und dann versucht, darauf zu schreiben, wird die Verbindung zurückgesetzt. setSoTimeout() soll Ihnen eine saubere Möglichkeit bieten, eine read() - Operation abzubrechen, die andernfalls für immer blockiert werden könnte, ohne schmutzige Dinge wie das Schließen des Sockets von einem anderen Thread.

43
erickson

Wann immer ich solche seltsamen Probleme hatte, setze ich mich normalerweise mit einem Tool wie WireShark hin und sehe mir die Rohdaten an, die hin und her übertragen werden. Sie könnten überrascht sein, wo Dinge getrennt werden, und Sie werden nur benachrichtigt, wenn Sie versuchen, zu lesen.

13
GEOCHET

Es ist peinlich, das zu sagen, aber als ich dieses Problem hatte, war es einfach ein Fehler, dass ich die Verbindung geschlossen habe, bevor ich alle Daten gelesen habe. In Fällen, in denen kleine Zeichenfolgen zurückgegeben wurden, hat es funktioniert, aber das lag wahrscheinlich daran, dass die gesamte Antwort gepuffert wurde, bevor ich sie geschlossen habe.

In Fällen, in denen längere Textmengen zurückgegeben wurden, wurde die Ausnahme ausgelöst, da mehr als ein Puffer zurückgegeben wurde.

Sie könnten nach diesem Versehen suchen. Denken Sie daran, dass das Öffnen einer URL einer Datei gleicht. Schließen Sie diese (lösen Sie die Verbindung), sobald sie vollständig gelesen wurde.

8
Scott S

Sie sollten die vollständige Spur sehr sorgfältig prüfen,

Ich habe eine Server-Socket-Anwendung und einen Java.net.SocketException: Connection reset - Fall behoben.

In meinem Fall geschieht dies beim Lesen eines clientSocket Socket -Objekts, dessen Verbindung aus irgendeinem Grund geschlossen wurde. (Netzwerk verloren, Firewall oder Anwendungsabsturz oder beabsichtigtes Schließen)

Eigentlich habe ich die Verbindung wiederhergestellt, als beim Lesen von diesem Socket-Objekt ein Fehler aufgetreten ist.

Socket clientSocket = ServerSocket.accept();
is = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
int readed = is.read(); // WHERE ERROR STARTS !!!

Das Interessante ist for my Java Socket, Wenn ein Client eine Verbindung zu meinem ServerSocket herstellt und die Verbindung schließt, ohne etwas zu senden. is.read() ruft sich selbst rekursiv auf Wenn Sie von dieser Buchse lesen, versuchen Sie, von einer geschlossenen Verbindung aus zu lesen. Wenn Sie für den Lesevorgang Folgendes verwenden:

while(true)
{
  Receive();
}

Dann bekommst du eine stackTrace wie unten immer weiter

Java.net.SocketException: Socket is closed
    at Java.net.ServerSocket.accept(ServerSocket.Java:494)

Ich habe lediglich ServerSocket geschlossen, meine Verbindung erneuert und auf weitere eingehende Client-Verbindungen gewartet

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


//...
}

Dies stellt meine Verbindung für unbekannte Client-Socket-Verluste wieder her

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

Ich konnte keinen anderen Weg finden, weil Sie, wie Sie in der Abbildung unten sehen, nicht verstehen können, ob die Verbindung ohne try and catch Unterbrochen wurde oder nicht, weil alles richtig zu sein scheint. Ich habe diesen Schnappschuss erhalten, während ich kontinuierlich Connection reset Erhalten habe.

enter image description here

8
Davut Gürbüz

Ich hatte den gleichen fehler Ich habe jetzt die Lösung für das Problem gefunden. Das Problem bestand darin, dass das Client-Programm beendet wurde, bevor der Server die Streams las.

5
kml_ckr

Ich hatte dieses Problem mit einem SOA in Java geschriebenen System. Ich habe sowohl den Client als auch den Server auf verschiedenen physischen Computern ausgeführt und sie haben lange Zeit einwandfrei funktioniert. Dann tauchten diese fiesen Verbindungszurücksetzungen in auf Das Client-Protokoll und nichts Ungewöhnliches im Server-Protokoll. Das Neustarten von Client und Server löste das Problem nicht. Schließlich stellten wir fest, dass der Heap auf der Serverseite ziemlich voll war, und erhöhten den für die JVM verfügbaren Speicher: Problem gelöst! Beachten Sie, dass sich kein OutOfMemoryError im Protokoll befand: Der Speicher war knapp und nicht erschöpft.

4
Pino

Ich hatte auch dieses Problem mit einem Java - Programm, das versuchte, einen Befehl über SSH auf einem Server zu senden. Das Problem bestand darin, dass der Computer den Java - Code ausführte Keine Berechtigung zum Herstellen einer Verbindung mit dem Remoteserver Die Methode write () hat funktioniert, aber die Methode read () hat eine Java.net.SocketException ausgelöst: Connection reset. Ich habe dieses Problem durch Hinzufügen des Client-SSH-Schlüssels behoben an den Remote-Server bekannte Schlüssel.

1
pmartin8

Überprüfen Sie die Java Version Ihres Servers. Ist mir passiert, weil sich mein Weblogic 10.3.6 auf JDK 1.7.0_75 befand, das sich auf TLSv1 befand. Der restliche Endpunkt, den ich zu konsumieren versuchte, hat alles unter TLSv1 heruntergefahren. 2.

Standardmäßig hat Weblogic versucht, das stärkste gemeinsam genutzte Protokoll auszuhandeln. Details finden Sie hier: Probleme beim Festlegen der https.protocols-Systemeigenschaft für HTTPS-Verbindungen .

Ich habe eine ausführliche SSL-Protokollierung hinzugefügt, um das unterstützte TLS zu identifizieren. Dies zeigt an, dass TLSv1 für den Handshake verwendet wurde.
-Djavax.net.debug=ssl:handshake:verbose:keymanager:trustmanager -Djava.security.debug=access:stack

Ich habe dieses Problem behoben, indem ich die Funktion auf unser JDK8-kompatibles Produkt übertragen habe. JDK8 verwendet standardmäßig TLSv1.2. Für diejenigen, die auf JDK7 beschränkt sind, habe ich auch eine Problemumgehung für Java 7 durch Upgrade auf TLSv1.2 erfolgreich getestet. Ich habe diese Antwort verwendet: So aktivieren Sie TLS 1.2 in Java 7

0
behold