Solve the problem of java. net. SocketTimeoutException: Read timed out

java.net.SocketTimeoutException: Read timed out

Problem environment: ssm+mysql+gridFS+tomcat

Problem code snippet:

public void write(OutputStream os, InputStream is) {
  try (BufferedOutputStream bos = new BufferedOutputStream(os); BufferedInputStream bis = new BufferedInputStream(is)) {
   int count;
   byte[] buffer = new byte[1024];
   while ((count = bis.read(buffer)) > 0) {
    bos.write(buffer, 0, count);
   }
   os.flush();
  } catch (IOException e) {
   e.printStackTrace();
  }
 }

Where the output stream is response. getOutPutStream ();

Cause of problem:

Because mongodb and the project are deployed on different servers, it takes a long time to read large files, which exceeds the lifetime of one connection limited by tomcat, resulting in tomcat judging that the connection timed out

Solution:

Modify server. xml in tomcat with the following configuration:

<Connector executor="tomcatThreadPool"
               port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000" disableUploadTimeout="false"
               redirectPort="8443" />

Add disableUploadTimeout= "false" to cancel the read-write connection timeout setting

Or

<Connector executor="tomcatThreadPool"
               port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
    keepAliveTimeout="100000"
               redirectPort="8443" />

Increase keepAliveTimeout= "100000" to increase connection lifetime

SocketException Common Anomalies

The first exception is java. net. BindException: Address already ES50use: JVM_Bind

This exception occurs when the server side performs an new ServerSocket (port) (port is an integer value of 0,65536) operation. The reason for the exception is that one port like port1 has been started and is listening. At this point, with the netstat an command, you can see a port in Listending status. You only need to find an unoccupied port to solve this problem.

The second exception is java. net. ConnectException: Connection refused: connect

This exception occurs when the client performs an new Socket (ip, port) operation because either the machine with the ip address cannot be found (that is, the route to the specified ip does not exist from the current machine), or the ip exists, but the specified port cannot be found for listening. If this problem occurs, first check whether the client's ip and port are written wrong. If it is correct, see if the server under the client's ping1 can pass ping. If it can pass ping (the service server needs another way to ban ping), then see if the program monitoring the specified port on the server is started, which will definitely solve this problem.

ConnectException: Connection refused: This exception also occurs when the client is multithreaded.

The third exception is java. net. SocketException: Socket is closed

This exception can occur on both the client and the server. The reason for the exception is that one's own side actively closes the connection (calling close method of Socket) and then reads and writes the network connection.

The fourth exception is java. net. SocketException: (Connection reset or Connect reset by peer: Socket write error)

This exception may occur on both the client and the server, and there are two reasons for this exception. The first is that if Socket on the first side is shut down (or actively shut down or shut down due to abnormal exit), the other side still sends data, and the first data packet sent throws this exception (Connect reset by peer). The other side exits without closing the connection, and throws the exception if the other side is reading data from the connection (Connection reset). Simply put, it is caused by read and write operations after the connection is disconnected.

The fifth exception is java. net. SocketException: Broken pipe

This exception can occur on both the client and the server. In the first case of the fourth exception (that is, after SocketExcepton: Connect reset by peer: Socket write error is thrown), the exception is thrown if the data continues to be written. The solution to the first two anomalies is to ensure that all network connections are closed before the program exits, and then to detect the other party's closing operation, and find that the other party should close the connection after closing the connection.