Official reasons for "Software caused connection abort: socket write error"

Given this stack trace snippet

Caused by: java.net.SocketException: Software caused connection abort: socket write error
 at java.net.SocketOutputStream.socketWrite0(Native Method)

I tried to answer the following questions:

1. What code is throwing this exception? (JVM?/Tomcat?/My code?)
2. What causes this exception to be thrown?

Regarding #1:

Sun's JVM source doesn't contain this exact message, but I think the text Software caused connection abort: socket write error is from the native implementation of SocketOutputStream:

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

Regarding #2

My guess is that it is caused when the client has terminated the connection, before getting the full response (e.g. sent a request, but before getting the full response, it got closed / terminated / offline)

Questions:

1. Are the above assumptions correct (#1 and #2)?
2. Can this be diffrentiated from the situation: "could not write to the client, due to a network error on the server side"? or would that render the same error message?
3. And most important: Is there an official document (e.g from Sun) stating the above?

I need to have a proof that this stack trace is the socket client's "fault", and there is nothing that the server could have done to avoid it. (except catching the exception, or using a non Sun JVM SocketOutputStream, though both don't really avoid the fact the client has terminated)

This error can occur when the local network system aborts a connection, such as when WinSock closes an established connection after data retransmission fails (receiver never acknowledges data sent on a datastream socket).

See this MSDN article. See also Some information about 'Software caused connection abort'.

The java.net.SocketException is thrown when there is an error creating or accessing a socket (such as TCP). This usually can be caused when the server has terminated the connection (without properly closing it), so before getting the full response. In most cases this can be caused either by the timeout issue (e.g. the response takes too much time or server is overloaded with the requests), or the client sent the SYN, but it didn't receive ACK (acknowledgment of the connection termination). For timeout issues, you can consider increasing the timeout value.

The Socket Exception usually comes with the specified detail message about the issue.

Example of detailed messages:

• Software caused connection abort: recv failed.

  The error indicates an attempt to send the message and the connection has been aborted by your server. If this happened while connecting to the database, this can be related to using not compatible Connector/J JDBC driver.

  Possible solution: Make sure you've proper libraries/drivers in your CLASSPATH.

• Software caused connection abort: connect.

  This can happen when there is a problem to connect to the remote. For example due to virus-checker rejecting the remote mail requests.

  Possible solution: Check Virus scan service whether it's blocking the port for the outgoing requests for connections.

• Software caused connection abort: socket write error.

  Possible solution: Make sure you're writing the correct length of bytes to the stream. So double check what you're sending. See this thread.

• Connection reset by peer: socket write error / Connection aborted by peer: socket write error

  The application did not check whether keep-alive connection had been timed out on the server side.

  Possible solution: Ensure that the HttpClient is non-null before reading from the connection.^E13222_01

• Connection reset by peer.

  The connection has been terminated by the peer (server).

• Connection reset.

  The connection has been either terminated by the client or closed by the server end of the connection due to request with the request.

  See: What's causing my java.net.SocketException: Connection reset?

I have seen this most often when a corporate firewall on a workstation/laptop gets in the way, it kills the connection.

eg. I have a server process and a client process on the same machine. The server is listening on all interfaces (0.0.0.0) and the client attempts a connection to the public/home interface (note not the loopback interface 127.0.0.1).

If the machine is has its network disconnected (eg wifi turned off) then the connection is formed. If the machine is connected to the corporate network (directly or vpn) then the connection is formed.

However, if the machine is connected to a public wifi (or home network) then the firewall kicks in an kills the connection. In this situation connecting the client to the loopback interface works fine, just not to the home/public interface.

Hope this helps.

To prove which component fails I would monitor the TCP/IP communication using wireshark and look who is actaully closing the port, also timeouts could be relevant.