java.net.SocketException: Connection Reset

Ik krijg de volgende foutmelding om te lezen van een socket. Ik doe een readInt()over die InputStream, en ik krijg deze fout. Door de documentatie door te nemen, suggereert dat het clientgedeelte van de verbinding de verbinding sloot. In dit scenario ben ik de server.

Ik heb toegang tot de clientlogbestanden en het sluit niet de verbinding en in feite suggereren de logbestanden die ik de verbinding sluit. Heeft iemand een idee waarom dit gebeurt? Wat moet ik nog meer controleren? Ontstond dit wanneer er lokale bronnen zijn die misschien de drempels bereiken?

Ik hoop dat ik de volgende regel heb:

socket.setSoTimeout(10000);

Vlak voorafgaand aan de readInt(). Er is een reden voor dit (lang verhaal), maar gewoon nieuwsgierig, zijn er omstandigheden waaronder dit kan leiden tot de aangegeven fout? Ik heb de server die in mijn IDE loopt, en ik zat mijn IDE vast te zitten op een breekpunt, en ik merkte toen dat exact dezelfde fouten beginnen te verschijnen in mijn eigen logs in mijn IDE.

Hoe dan ook, vermeld het gewoon, hopelijk geen rode haring. : – (

Antwoord 1, Autoriteit 100%

Er zijn verschillende mogelijke oorzaken.

1. Het andere uiteinde is opzettelijk de verbinding gereset, op een manier die ik hier niet zal documenteren. Het is zeldzaam en in het algemeen onjuist, voor toepassingssoftware om dit te doen, maar het is niet onbekend voor commerciële software.

2. Gewoonlijk, het wordt veroorzaakt door het schrijven aan een verbinding die het andere uiteinde al normaal is gesloten. Met andere woorden een aanvraagprotocolfout.

3. Het kan ook worden veroorzaakt door het sluiten van een socket wanneer er ongelezen gegevens in de contactbuffer ontvangen.

4. In Windows, ‘Software veroorzaakte aansluiting ABort’, die niet hetzelfde is als ‘Connection Reset’, wordt veroorzaakt door netwerkproblemen die vanaf uw einde worden verzonden. Er is een Microsoft Knowledge Base-artikel hierover.

Antwoord 2, Autoriteit 44%

Verbindingsreset betekent gewoon dat een TCP RST is ontvangen. Dit gebeurt wanneer uw peer gegevens ontvangt die het niet kan verwerken, en er kunnen daarvoor verschillende redenen zijn.

De eenvoudigste is wanneer u het stopcontact sluit en vervolgens meer gegevens op de uitgangsstroom kunt schrijven. Door de socket te sluiten, vertelde u uw peer dat u klaar bent met praten, en het kan uw verbinding vergeten. Wanneer u hoe dan ook meer gegevens op die stroom verzendt, verwerpt de peer het met een RST om u te laten weten dat het niet luistert.

In andere gevallen kan een tussenliggende firewall of zelfs de externe host zelf “vergeten” over uw TCP-verbinding. Dit kan gebeuren als u geen gegevens voor een lange tijd verzendt (2 uur is een gemeenschappelijke time-out), of omdat de peer opnieuw werd opgestart en zijn informatie over actieve verbindingen kwijtraakt. Gegevens verzenden op een van deze defunct-verbindingen zal ook een RST veroorzaken.

Update in reactie op aanvullende informatie:

Neem een ​​kijkje op uw afhandeling van de SocketTimeoutException. Deze uitzondering wordt verhoogd als de geconfigureerde time-out wordt overschreden terwijl wordt geblokkeerd op een socket-werking. De staat van de socket zelf is niet gewijzigd wanneer deze uitzondering wordt gegooid, maar als uw uitzonderingshandler het stopcontact sluit, en probeert deze te schrijven, bevindt u zich in een voorwaarden voor de reset. setSoTimeout()is bedoeld om u een schone manier te geven om uit te breken met een read()bediening die anders kan blokkeren, zonder vuile dingen te doen zoals het sluiten van de socket van een ander draad.

Antwoord 3, Autoriteit 16%

Als ik vreemde problemen als deze heb gehad, ga ik meestal zitten met een tool zoals WireSharken kijk naar de onbewerkte gegevens worden heen en weer doorgegeven. Je zult er misschien versteld van staan waar dingen worden losgekoppeld en je wordt alleen op de hoogte gesteldwanneer je probeert te lezen.

Antwoord 4, autoriteit 9%

U moet de volledige tracering zeer zorgvuldig inspecteren,

Ik heb een server-sockettoepassing en heb een java.net.SocketException: Connection reset-geval opgelost.

In mijn geval gebeurt het tijdens het lezen van een clientSocket Socket-object waarvan de verbinding om de een of andere reden is verbroken. (Netwerk verloren, firewall of applicatie crasht of wil sluiten)

Eigenlijk was ik de verbinding aan het herstellen toen ik een foutmelding kreeg tijdens het lezen van dit Socket-object.

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

Het interessante is for my JAVA Socketals een client verbinding maakt met mijn ServerSocketen de verbinding verbreekt zonder iets is.read()wordt herhaaldelijk aangeroepen. Het lijkt erop dat u in een oneindige while-lus voor het lezen van deze socket probeert te lezen vanuit een gesloten verbinding.
Als u iets als hieronder gebruikt voor de leesbewerking;

while(true)
{
  Receive();
}

Dan krijg je een stackTrace, zoiets als hieronder, door en door

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

Wat ik deed, is gewoon ServerSocket sluiten en mijn verbinding vernieuwen en wachten op verdere inkomende clientverbindingen

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

Hiermee wordt mijn verbinding opnieuw tot stand gebracht voor onbekende client-socket-verliezen

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

Ik kon geen andere manier vinden, want zoals je op onderstaande afbeelding kunt zien, kun je niet begrijpen of de verbinding is verbroken of niet zonder een try and catch, omdat alles goed lijkt te zijn. Ik kreeg deze momentopname terwijl ik voortdurend Connection resetkreeg.

Antwoord 5, autoriteit 8%

Beschamend om te zeggen, maar toen ik dit probleem had, was het gewoon een vergissing dat ik de verbinding verbrak voordat ik alle gegevens had gelezen. In gevallen waarin kleine strings werden geretourneerd, werkte het, maar dat was waarschijnlijk te wijten aan het feit dat het hele antwoord was gebufferd voordat ik het sloot.

In het geval dat er grotere hoeveelheden tekst werden geretourneerd, werd de uitzondering gegenereerd, omdat er meer dan een buffer terugkwam.

U kunt dit onoplettendheid controleren. Onthoud dat het openen van een URL is als een bestand, sluit het (laat de verbinding los) zodra het volledig is gelezen.

Antwoord 6, autoriteit 5%

Ik had dezelfde fout. Ik heb nu de oplossing voor het probleem gevonden. Het probleem was dat het clientprogramma klaar was voordat de server de streams las.

Antwoord 7, autoriteit 2%

Ik had dit probleem met een SOA-systeem geschreven in Java. Ik draaide zowel de client als de server op verschillende fysieke machines en ze werkten lange tijd prima, toen verschenen die vervelende verbindingsresets in het clientlogboek en er was niets vreemds in het serverlogboek. Het opnieuw opstarten van zowel de client als de server loste het probleem niet op. Uiteindelijk ontdekten we dat de heap aan de serverkant nogal vol was, dus hebben we het beschikbare geheugen voor de JVM vergroot: probleem opgelost! Merk op dat er geen OutOfMemoryError in het logboek stond: het geheugen was gewoon schaars, niet uitgeput.

Antwoord 8

Ik had dit probleem ook met een Java-programma dat via SSH een opdracht op een server probeerde te verzenden. Het probleem was dat de machine de Java-code uitvoerde. Het had niet de toestemming om verbinding te maken met de externe server. De methode write() deed het goed, maar de methode read() gaf een java.net.SocketException: verbinding opnieuw instellen. Ik heb dit probleem opgelost door de SSH-sleutel van de client toe te voegen aan de bekende sleutels van de externe server.

Antwoord 9

Controleer de Java-versie van uw server. Het overkwam mij omdat mijn Weblogic 10.3.6 op JDK 1.7.0_75 stond, dat op TLSv1 stond. Het resteindpunt dat ik probeerde te consumeren, was het afsluiten van alles onder TLSv1.2.

Weblogic probeerde standaard te onderhandelen over het sterkste gedeelde protocol. Bekijk hier details: Problemen met het instellen van https.protocols Systeemeigenschap voor HTTPS-verbindingen.

Ik heb uitgebreide SSL-logboekregistratie toegevoegd om de ondersteunde TLS te identificeren. Dit gaf aan dat TLSv1 werd gebruikt voor de handdruk.
-Djavax.net.debug=ssl:handshake:verbose:keymanager:trustmanager -Djava.security.debug=access:stack

Ik heb dit opgelost door de functie naar ons JDK8-compatibele product te pushen, JDK8 is standaard ingesteld op TLSv1.2. Voor degenen die beperkt zijn tot JDK7, heb ik ook met succes een tijdelijke oplossing voor Java 7 getest door te upgraden naar TLSv1.2. Ik gebruikte dit antwoord: Hoe TLS 1.2 in Java 7 in te schakelen

Antwoord 10

In mijn ervaring kom ik vaak de volgende situaties tegen;

1. Als u in een zakelijk bedrijf werkt, neem dan contact op met het netwerk- en beveiligingsteam. Omdat het bij verzoeken aan externe services nodig kan zijn om toestemming te geven voor het betreffende eindpunt.

2. Een ander probleem is dat het SSL-certificaat is verlopenop de server waarop uw applicatie draait.

Antwoord 11

In mijn geval was DNS problem.
Ik heb in host filehet opgeloste IP-adres geplaatst en alles werkt prima.
Het is natuurlijk geen permanente oplossing, maar dit geeft me de tijd om het DNS-probleem op te lossen.

Antwoord 12

Ik heb dit probleem gezien. In mijn geval was er een fout opgetreden door het hergebruik van hetzelfde clientrequest-object in een specifieke Java-klasse. Dat project gebruikte Jboss Restasy .

1. In eerste instantie gebruikte / roept / roept / roept het Object ClientRequest (geplaatst als globale variabele in de klas) om een verzoek in een specifieke URL te doen.
2. Daarna is een andere methode gemaakt om gegevens te ontvangen met een andere URL, hetzelfde voorwerp van hetzelfde clientrequest-object.

De oplossing: in dezelfde klasse werd een ander clientrequest-object en uitsluitend gemaakt om niet opnieuw te worden gebruikt.