How to solve the error java.net.SocketException: Connection reset

A SocketException Connection reset is one of the most common Runtime errors you can find in Java applications. As the name implies, it happens during a network connection which terminates abruptly. In this tutorial we will teach you which is the best action plan to find the root cause of the issue.

What is a “Connection reset” and which are the possible causes?

“Connection reset” simply means that you received a TCP RST. This occurs when your peer receives data that it can’t process, and there can be various reasons for this. The simplest one is when you close the socket and then write more data on the output stream. Then, when you send more data on that stream anyway, the peer rejects it with an RST to let you know it isn’t listening.

A slightly different case is “java.net.SocketException: Connection reset by peer”. This error hints that the remote host sent the connection reset (i.e., the host that the Java application is connecting to).

There are several possible causes for this error, such as:

Firewall

Firstly, if the firewall has a rule that blocks all incoming traffic from the client, it may send an RST packet to the server to reset the connection as soon as it receives a SYN packet from the client.

Also, if the firewall has a rule that allows incoming traffic from the client, but blocks all outgoing traffic from the server to the client, it may send an RST packet to the client to reset the connection when it receives a SYN-ACK packet from the server.

Then, if the firewall has a rule that allows incoming traffic from the client, but blocks all outgoing traffic from the server to the client based on the port number or protocol, it may send an RST packet to the client to reset the connection when it receives a SYN-ACK packet from the server.

Finally, if the firewall has a rule that allows incoming traffic from the client, but blocks all outgoing traffic from the server to the client based on the content of the packets, it may send an RST packet to the client to reset the connection when it receives a SYN-ACK packet from the server that contains data that matches the specified criteria.

Network Scanner

A network scanner can cause a TCP connection RESET between a client and a server by sending a forged RST packet to one or both of the devices.

For example, a network scanner could send a forged RST packet to the client, pretending to be the server. The client would receive the RST packet and believe that the server wants to reset the connection. So it would send an RST packet back to the server and close the connection.

Alternatively, the network scanner could send a forged RST packet to the server, pretending to be the client. The server would receive the RST packet and believe that the client wants to reset the connection, so it would send an RST packet back to the client and close the connection.

In either case, the network scanner could use this technique to disrupt the communication between the client and the server.

Network switch

A network switch can cause a TCP connection RESET between a client and a server when the connection is idle if the switch has a feature called “TCP idle timeout” enabled. This feature allows the switch to close idle TCP connections after a certain period of inactivity. This will result in a premature termination of the connection between the client and the server at the network layer.

Databases

In some cases, the database server may be terminating the connection. This can be due, for example, to a configuration (e.g. timeout period) of the Database server. It can also be related to a defect in the Database driver.

You can manage most of database timeouts/stale connection issues with a proper configuration of Datasource validation. Learn more here: How to validate Database connections in JBoss / WildFly

Client application

Finally, there can be an issue with the Java Client application connecting to the server. A common case is a bug in the software. But it can be as well a misconfiguration or something in the Client OS settings

Finding the root cause

After discussing all possible causes of a “java.net.SocketException: Connection reset”, let’s see how to find the root cause. If your server logs/system log do not provide any extra clue, the best option is to start a dump session.

Here are some things to look for in a dump session:

• If the client is initiating the disconnect, it will typically send a FIN packet to the server to close the connection. You can use tcpdump or a similar tool to capture and inspect the packets being sent over the network.
• If the server is initiating the disconnect, it will typically send a RST packet in response to a client request, or close the connection after a period of inactivity. You can use tcpdump or a similar tool to capture and inspect the packets being sent over the network.

For example, Linux users can start the tcpdump command:

 tcpdump -i eth0  port 8080  and '(tcp-syn|tcp-rst)!=0' 

The above tcpdump command will list SYN (connection attempts) and RST (reset connections) on port 8080. Let’s see a practical example:

$ netstat -na

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN

$ tcpdump -i eth0  port 8080  and '(tcp-syn|tcp-rst)!=0' 

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:34:50.569441 IP localhost.8080 > localhost.41300: Flags [S], seq 1779073596, win 65535, options [mss 65495,sackOK,TS val 838312 ecr 0,nop,wscale 7], length 0
20:34:50.569474 IP localhost.41300 > localhost.8080: Flags [R], seq 0, win 0, length 0

This dump shows that the client is sending a SYN packet to initiate the connection. Then, the server is sending a RST packet to reset the connection. For example, it could be a firewall blocking the connection. You can use tools such as iptables or ufw to view and configure the firewall rules on the system.

Conclusion

This article was a walk through the analysis of the Connection reset error in a Java applicaion. In most cases, to further understand the cause of the error, you can try examining other packets being exchanged between the client and server, and analyzing the system activity.