Dato questo frammento di traccia dello stack
Causato da: java.net.SocketException: Il software ha causato l'interruzione della connessione: errore di scrittura socket
a java.net.SocketOutputStream.socketWrite0 (Native Metodo)
Ho provato a rispondere alle seguenti domande:
- Quale codice genera questa eccezione? (JVM? / Tomcat? / Il mio codice?)
- Che cosa provoca questa eccezione?
Per quanto riguarda il n. 1:
La fonte JVM di Sun non contiene questo messaggio esatto, ma penso che il testo Il software ha causato l'interruzione della connessione: errore di scrittura del socket proviene dall'implementazione nativa di SocketOutputStream:
private native void socketWrite0(FileDescriptor fd, byte[] b, int off,
int len) throws IOException;
Per quanto riguarda il n. 2
La mia ipotesi è che è causato quando il client haha terminato la connessione, prima di ottenere la risposta completa (ad es. ha inviato una richiesta, ma prima di ottenere la risposta completa, è stata chiusa / terminata / offline)
Domande:
- I presupposti di cui sopra sono corretti (n. 1 e n. 2)?
- Questo può essere differenziato dalla situazione: "impossibile scrivere sul client, a causa di un errore di rete sul server side "? o che renderebbe lo stesso messaggio di errore?
- E soprattutto: Esiste un documento ufficiale (ad esempio di Sun) che afferma quanto sopra?
Devo avere una prova che questa traccia dello stack èl '"errore" del client socket, e non c'è nulla che il server avrebbe potuto fare per evitarlo. )
risposte:
47 per risposta № 1"Questo errore può verificarsi quando la rete localeil sistema interrompe una connessione, ad esempio quando WinSock chiude una connessione stabilita dopo il fallimento della ritrasmissione dei dati (il destinatario non riconosce mai i dati inviati su un socket del flusso di dati). " questo articolo MSDN. Guarda anche Alcune informazioni su "Il software ha causato l'interruzione della connessione".
9 per risposta № 2
L'ho visto il più delle volte quando un firewall aziendale su una workstation / laptop si intromette, uccide la connessione.
per esempio. Ho un processo server e un processo client sulla stessa macchina. Il server è in ascolto su tutte le interfacce (0.0.0.0) e il client tenta una connessione all'interfaccia pubblica / domestica (notare non l'interfaccia di loopback 127.0.0.1).
Se la macchina ha la rete disconnessa (ad es. Wifi disattivato), viene stabilita la connessione. Se la macchina è connessa alla rete aziendale (direttamente o vpn), viene formata la connessione.
Tuttavia, se la macchina è connessa a un pubblicowifi (o rete domestica) quindi il firewall avvia e uccide la connessione. In questa situazione, la connessione del client all'interfaccia di loopback funziona correttamente, ma non all'interfaccia home / pubblica.
Spero che questo ti aiuti.
4 per risposta № 3
Per provare quale componente non funziona, monitorerei la comunicazione TCP / IP utilizzando Wireshark e guarda chi sta attivamente chiudendo la porta, anche i timeout potrebbero essere rilevanti.
3 per risposta № 4
Il java.net.SocketException viene generato quando si verifica un errore durante la creazione o l'accesso una presa (ad esempio TCP). Questo di solito può essere causato quando il server ha terminato la connessione (senza chiuderla correttamente), quindi prima di ottenere la risposta completa. Nella maggior parte dei casi ciò può essere causato dal problema di timeout (ad es. La risposta richiede troppo tempo o il server è sovraccarico di richieste) o il client ha inviato il SYN, ma non ha ricevuto ACK (riconoscimento della terminazione della connessione) Per problemi di timeout, puoi considerare di aumentare il valore di timeout.
L'eccezione socket di solito viene fornito con il messaggio di dettaglio specificato sul problema.
Esempio di messaggi dettagliati:
Il software ha causato l'interruzione della connessione: recv non riuscita.
L'errore indica un tentativo di inviare il messaggio e la connessione è stata interrotta dal server. Se ciò si è verificato durante la connessione al database, ciò può essere correlato all'utilizzo driver JDBC connettore / J non compatibile.
Possibile soluzione: assicurati di avere librerie / driver corretti nel tuo CLASSPATH.
Il software ha causato l'interruzione della connessione: connettersi.
Ciò può accadere in caso di problemi con la connessione al telecomando. Per esempio a causa del controllo antivirus che rifiuta le richieste di posta remota.
Possibile soluzione: verificare se il servizio di scansione antivirus sta bloccando la porta per le richieste in uscita per le connessioni.
Il software ha causato l'interruzione della connessione: errore di scrittura del socket.
Possibile soluzione: assicurati di scrivere la lunghezza corretta di byte nello stream. Quindi ricontrolla ciò che stai inviando. Guarda questo filo.
Connessione ripristinata dal peer: errore di scrittura socket / Connessione interrotta dal peer: errore di scrittura socket
L'applicazione non ha verificato se la connessione keep-alive era stata scaduta sul lato server.
Possibile soluzione: assicurarsi che HttpClient sia diverso da null prima di leggere dalla connessione.E13222_01
Connessione ripristinata dal peer.
La connessione è stata terminata dal peer (server).
Reset della connessione.
La connessione è stata terminata dal client o chiusa dall'estremità del server della connessione a causa della richiesta con la richiesta.
Vedere: Cosa sta causando il mio java.net.SocketException: connessione ripristinata?
2 per risposta № 5
Hai controllato il codice sorgente Tomcat e la fonte JVM? Questo potrebbe darti più aiuto.
Penso che il tuo pensiero generale sia buono. Mi aspetterei a ConnectException nello scenario che non è stato possibile connettersi. Quanto sopra sembra molto simile al client.
2 per risposta № 6
Per chiunque utilizzi semplici programmi Client Server e ottenga questo errore, si tratta di un problema di flussi di input o output non chiusi (o chiusi all'inizio).
1 per risposta № 7
Stavo affrontando lo stesso problema.
Comunemente Questo tipo di errore si verifica a causa della chiusura della connessione del client e il server sta ancora tentando di scrivere su quel client.
Quindi assicurati che il tuo client abbia la connessione aperta fino a quando il server non ha terminato il suo outputstream.
E un'altra cosa, non dimenticartene chiudere il flusso di input e output.
Spero che questo ti aiuti.
E se stai ancora affrontando un problema, consulta il tuo problema qui in dettaglio.
0 per risposta № 8
Questo errore mi è successo durante il test del mio servizio soap con il client SoapUI, fondamentalmente stavo cercando di ottenere un messaggio molto grande (> 500kb) e SoapUI ha chiuso la connessione per timeout.
Su SoapUI vai a:
File -> Preferenze - Timeout socket (ms)
... e metti un valore grande, come 180000 (3 minuti), questo non sarà la soluzione perfetta per il tuo problema perché il file è in realtà di grandi dimensioni, ma almeno avrai una risposta.
0 per risposta № 9
Nel mio caso, l'errore era:
java.net.SocketException: Software caused connection abort: recv failed
È stato ricevuto in eclissi durante il debug di un javaapplicazione che accede a un database H2. La fonte dell'errore era che avevo inizialmente aperto il database con SQuirreL per verificare manualmente l'integrità. Ho usato il flag per abilitare più connessioni allo stesso DB (ad es. AUTO_SERVER=TRUE), quindi non si sono verificati problemi durante la connessione al DB da Java.
L'errore è apparso quando, dopo un po ', è alungo processo Java: ho deciso di chiudere SQuirreL per liberare risorse. Sembra che SQuirreL fosse quello "proprietario" dell'istanza del server DB e che sia stato chiuso con la connessione SQuirreL.
Il riavvio dell'applicazione Java non ha prodotto nuovamente l'errore.
config
- Windows 7
- Eclipse Keplero
- SQuirreL 3.6
- org.h2.Driver ver 1.4.192
-1 per risposta № 10
Il mio server ha lanciato questa eccezione nel passaggio 2 giorni e l'ho risolto spostando la funzione di disconnessione con:
outputStream.close();
inputStream.close();
Client.close();
Alla fine del thread dell'elenco. se aiuterà qualcuno.
-1 per risposta № 11
Nella situazione spiegata di seguito, il lato client genererà tale eccezione:
Al server viene richiesto di autenticare il clientcertificato, ma il client fornisce un certificato per cui l'utilizzo della chiave estesa non supporta l'autenticazione del client, quindi il server non accetta il certificato del client e quindi chiude la connessione.
-3 per risposta № 12
Stavo affrontando lo stesso problema con wireMock mentre prendevo in giro le altre chiamate API. Prima stavo definendo il server in questo modo:
WireMockServer wireMockServer = null;
Ma dovrebbe essere definito come mostrato di seguito:
@Rule
public WireMockRule wireMockRule = new WireMockRule(8089);