88

I haven't been able to find an adequate answer to what exactly the following error means:

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

Notes:

  • This error is infrequent and unpredictable; although getting this error means that all future requests for URIs will also fail.
  • The only solution that works (also, only occasionally) is to reboot Tomcat and/or the actual machine (Windows in this case).
  • The URI is definitely available (as confirmed by asking the browser to do the fetch).

Relevant code:

BufferedReader reader;
try { 
 URL url = new URL(URI);
 reader = new BufferedReader(new InputStreamReader(url.openStream())));
} catch( MalformedURLException e ) { 
 throw new IOException("Expecting a well-formed URL: " + e); 
}//end try: Have a stream

String buffer;
StringBuilder result = new StringBuilder();
while( null != (buffer = reader.readLine()) ) { 
 result.append(buffer); 
}//end while: Got the contents.
reader.close();
grammar31
  • 1,910
  • 1
  • 12
  • 17
  • 4
    Hey there. You marked the answer as correct - any chance you remember what you found by doing some sniffing? This problem has got me. (See my question http://stackoverflow.com/questions/6772215/java-net-socketexception-software-caused-connection-abort-recv-failed-with-jav) – nasty pasty Jul 21 '11 at 06:52
  • 1
    I am also having this problem. The only solution is to reboot the entire machine. Anyone have a complete answer? – Kevin Wong Apr 13 '12 at 13:32
  • @KevinWong The solution is to fix the network. – user207421 Mar 29 '15 at 00:17
  • 6
    @EJP Kinda funny that the question that was "asked before" was asked two years after this one :-) – grammar31 Mar 17 '16 at 17:25

10 Answers10

30

This usually means that there was a network error, such as a TCP timeout. I would start by placing a sniffer (wireshark) on the connection to see if you can see any problems. If there is a TCP error, you should be able to see it. Also, you can check your router logs, if this is applicable. If wireless is involved anywhere, that is another source for these kind of errors.

AdamC
  • 15,761
  • 7
  • 48
  • 66
30

This also happens if your TLS client is unable to be authenticate by the server configured to require client authentication.

desbocages
  • 309
  • 3
  • 2
  • No it doesn't. That causes the server to close the connecton properly with a TLS `close_notify`. No resets at all, or at best 'connection reset by peer'. – user207421 Mar 28 '15 at 22:33
  • 2
    It did happen to me with some API when authentication failed. So thanks @desbocages. – Eddy Apr 05 '16 at 06:03
  • This was the cause of the error with my apache setup – Atuos May 03 '16 at 09:53
  • When connecting to an Apache Tomcat 7.0.42 server with mutual auth required, I received this exact error when attempting to authenticate with a cert whose trust chain was not in the list of trusted certs supplied by Tomcat during the SSL handshake. Incidentally, the cert I was using to authenticate was in the trust list but its trust chain was not and this error still occurred. – Daniel Oct 06 '16 at 17:40
  • 1
    I got "java.net.SocketException: Software caused connection abort: recv failed" client side and checked server side (Apache HTTPD) log file and saw "Certificate Verification: Error (10): certificate has expired". Mutual authentication is configured and my client cert was expired. Disappointing client can't get a more telling error message. – Ryan Feb 21 '19 at 18:04
11

This error occurs when a connection is closed abruptly (when a TCP connection is reset while there is still data in the send buffer). The condition is very similar to a much more common 'Connection reset by peer'. It can happen sporadically when connecting over the Internet, but also systematically if the timing is right (e.g. with keep-alive connections on localhost).

An HTTP client should just re-open the connection and retry the request. It is important to understand that when a connection is in this state, there is no way out of it other than to close it. Any attempt to send or receive will produce the same error.

Don't use URL.open(), use Apache-Commons HttpClient which has a retry mechanism, connection pooling, keep-alive and many other features.

Sample usage:

HttpClient httpClient = HttpClients.custom()
            .setConnectionTimeToLive(20, TimeUnit.SECONDS)
            .setMaxConnTotal(400).setMaxConnPerRoute(400)
            .setDefaultRequestConfig(RequestConfig.custom()
                    .setSocketTimeout(30000).setConnectTimeout(5000).build())
            .setRetryHandler(new DefaultHttpRequestRetryHandler(5, true))
            .build();
// the httpClient should be re-used because it is pooled and thread-safe.

HttpGet request = new HttpGet(uri);
HttpResponse response = httpClient.execute(request);
reader = new BufferedReader(new InputStreamReader(response.getEntity().getContent()));
// handle response ...
rustyx
  • 73,455
  • 21
  • 176
  • 240
  • No it doesn't. That causes 'connection reset by peer'. The OP's error is not caused by programming. – user207421 Mar 28 '15 at 22:29
  • 5
    Yes it does. I suggest you do some research before giving a -1. We actually did. 'Connection reset' is caused by the TCP RST packet, but when the TCP RST is received while there is still data in the send buffer, a subsequent `recv()` from the application will cause a `WSAECONNABORTED` error which translates into the exception in question. I wonder what *your* explanation is for this exception. "Fix the network" you say - I can reproduce this on localhost with a few lines of code. – rustyx Mar 29 '15 at 16:45
  • You are still conflating 'connection reset'with 'software caused connection abort'. They are two different conditions. – user207421 Mar 29 '15 at 18:33
  • I'm giving you an explanation, why do you still cling to some deeper semantics of these error codes? 'Software caused connection abort' is a ridiculous name for an error code but it means exactly what it says, only it doesn't mean *your* software, it means WinSock software. No application is explicitly closing a connection and then doing a `recv()` on it, that would be an easy fix, wouldn't it. – rustyx Mar 29 '15 at 19:24
  • We can't discuss this if you're just going to keep putting words into my mouth. I haven't said anything about 'recv().` I'm not responsible for the wording of the error message either. You're arguing with Microsoft here. See the citation in my answer to the duplicated question](http://stackoverflow.com/questions/2126607/official-reasons-for-software-caused-connection-abort-socket-write-error). – user207421 Mar 29 '15 at 19:50
  • 2
    Honestly I haven't heard you talk about anything substantial so far. Only flames and "-1"s. Do some research, then maybe you'll know what role WinSock, recv and TCP RST play in this case. – rustyx Mar 29 '15 at 20:27
  • I see that Google recommends now to use Volley to make the network requests https://developer.android.com/training/volley/simple – Dan Alboteanu Aug 01 '20 at 21:29
4

Are you accessing http data? Can you use the HttpClient library instead of the standard library? The library has more options and will provide better error messages.

http://hc.apache.org/httpclient-3.x/

Ken
  • 2,074
  • 1
  • 19
  • 16
4

The only time I've seen something like this happen is when I have a bad connection, or when somebody is closing the socket that I am using from a different thread context.

pfranza
  • 3,204
  • 2
  • 20
  • 34
2

Try adding 'autoReconnect=true' to the jdbc connection string

Anantharaman
  • 67
  • 1
  • 6
1

This will happen from time to time either when a connection times out or when a remote host terminates their connection (closed application, computer shutdown, etc). You can avoid this by managing sockets yourself and handling disconnections in your application via its communications protocol and then calling shutdownInput and shutdownOutput to clear up the session.

Michael J. Gray
  • 9,494
  • 6
  • 37
  • 66
1

Look if you have another service or program running on the http port. It happened to me when I tried to use the port and it was taken by another program.

trinity
  • 21
  • 1
0

If you are using Netbeans to manage Tomcat, try to disable HTTP monitor in Tools - Servers

Maroš Košina
  • 146
  • 2
  • 11
0

I too had this problem. My solution was:

sc.setSoLinger(true, 10);

COPY FROM A WEBSITE -->By using the setSoLinger() method, you can explicitly set a delay before a reset is sent, giving more time for data to be read or send.

Maybe it is not the answer to everybody but to some people.

Unihedron
  • 10,601
  • 13
  • 59
  • 69
Sergio
  • 19
  • 1
  • 3
    This is incorrect. SO_LINGER doesn't do any such thing. It controls how long `close()` blocks for, if at all. It has nothing to do with the timing of resets. And 'copy from a website' isn't a proper form of citation. You should provide the link so we can see what it really says, and if necessary comment adversely there too. I know [where you got that from](http://www.davidreilly.com/java/java_network_programming/), and it is grade A drivel from start to finish. I sent him a load of corrections about 15 years ago: he threw a tantrum and hasn't updated it since. – user207421 Mar 28 '15 at 22:40