HTTP500 wrong with Keep-Alive

Recently online frequent HttpServerErrorException: 500 anomalies, but not strong regularity, by querying the server error log found type:

org.apache.http.NoHttpResponseException: 21.153.143.183:8080 failed to respond

By querying the information found with the exception of a Http Header parameters Connection: Keep-Alive about, we are using the Apache httpclient.

  • To give a solution, it is very simple, when initializing HttpClient, use the following configuration, mainly NoConnectionReuseStrategy.INSTANCE parameters:
httpclient = HttpClientBuilder.create() 
.setMaxConnPerRoute(20) 
.setConnectionReuseStrategy(NoConnectionReuseStrategy.INSTANCE) //解决NoHttpResponseException问题 
.setMaxConnTotal(200) 
.build(); 

The purpose of this request is no longer a time multiplex link, but to create a new link.

  • The following analysis appears under the cause of the abnormality, and why the above methods can solve this problem

HTTP1.1 use the default request Connection: Keep-Alive parameters, indicating that the link should be maintained after the server receives the request will remain linked, waiting for the next request. And this keep-alive is valid, the client and server configuration effective time, the impact on the system is very large.

The service uses the springboot (1.5.9) comes tomcat container KeepAliveTimeout default, this general statement is the default value is 20 seconds, the commuting AbstractEndpoint code view, soTimeout default value, as follows:

 soTimeout default 20 seconds.

 In fact not the case, when you start to go through the debug springboot services, you can reach the position the following code:

That is soTimeout was changed to 60 seconds. OK, the server keepaliveTimeout 60 seconds.

The default keepaliveTimeout client by turning the code, discovered there was 15 minutes  .

Client 15-minute timeout, and the service ends 60-second timeout, the gap is not a little bit, can be learned by the next packet capture, tcp interactive process, service port 8090:

tcp by 3-way handshake to establish a connection, the connection is closed 4-way handshake can see the position indicated by the arrows, port 8090 is connected to port 50638. Establish the connection process is normal, but when you close link server just wishful thinking made a Fin package, the client does not respond Fin package (this time the connection is not available), if this is not available using httpclient connection request will send anti students not response exception. So after 15 minutes, the client Fin, the server said that the connection does not exist ah, Reset it.

 

Solutions mentioned above, to avoid the repeated use of expired connection, there would be no NoHttpResponseException exception; but this method is not a cure indicator, the system planted a lot of hidden dangers. The next article again on this issue for further analysis.

 

Guess you like

Origin www.cnblogs.com/yunnick/p/11290429.html
Recommended