I have a Java web project, because some requirements on business, must provide interface to external and internal is through a third-party service to satisfy demand, overall is a transit query, can, of course, from the project I review the log, convenient statistics, such as


But the problem is coming, the third party service because of various reasons, there are a few slow interface, often more than 1 s, sometimes even a few seconds to return, on-line has happened a few times after the accident, the reason is the client a large number of requests to the service, I again to passthrough the past, because the return is too slow, I have run out of fd and lead to feign death, although process is still there, but the request was not to go, a problem, check the network connection, CLOSE_WAIT up to tens of thousands, only restart the application rescue, but it is a ticking time bomb, who also don't know which day is hanged,

Currently use network tools is old kao of HttpClient encapsulation based project, after the normal request releases resources, take the initiative to close off abroad several times after the accident, each time, set the timeout time shorter, the original is 10 seconds, and now has been changed to 3 seconds,


But feel so always take temporary solution not effect a permanent cure, if the three interfaces is really slow, even a successful request each block in a few seconds, the client request if increases, can also lead to handle to Linux system running out, have any good solution? Alternative to HttpClient call?

CodePudding user response:

Whether can use HttpClient tools and use of the tools to business information code posted, speculation is HttpClient is not properly release the FD Linux server connection deduced

CodePudding user response:

And HttpClient version said

CodePudding user response:

1. If the call interface is iterative invocation pattern, you provide the batch interface, it can be each other's repeated requests to control access to a third party by oneself, benefit is completely controllable, can according to the actual situation of this pile of data calls or into small batch multi-thread calls,
2. Add machines, distributed deployment,
3. An asynchronous callback mode, this is just a way of thinking, character does not meet your business is not clear,

CodePudding user response:

And don't know how to use your httpclient, and didn't add the connection pool

CodePudding user response:

reference 1/f, hidden in the temple of the reply:

whether can use HttpClient tools and use tools to business information code posted, speculation is HttpClient is not properly release the connection leads to a Linux server run out of FD

We currently use HttpClient package version is 4.5.5, mainly use the method of encapsulation is (is also coming from other project copy)

Public static String postJsonStrForBusData (url String, the String jsonParam) {
LOGGER. The info (" request url: "+ url +", request parameters: "+ jsonParam);
CloseableHttpResponse response=null;
HttpPost HttpPost=null;
CloseableHttpClient httpClient=null;
Try {
HttpClient=HttpClients. Custom (.) disableAutomaticRetries (). The build ();
HttpPost=new httpPost (url);
//set the ultra time
HttpPost. SetConfig (* * * a timeout, and omit here * * *);
StringEntity entity=new StringEntity (jsonParam, "utf-8");
The entity. SetContentEncoding (" utf-8 ");
The entity. The setContentType (" application/json ");
HttpPost. SetEntity (entity);
The response=httpClient. Execute (httpPost);
Int statusCode=response. GetStatusLine (.) getStatusCode ();
If (statusCode!=HttpStatus. SC_OK) {
HttpPost. Abort ();
LOGGER. The error (" HttpClient, error status code: "+ statusCode);
return null;
}
HttpEntity resultEntity=response. GetEntity ();
The String result=null;
If (resultEntity!=null) {
Result=EntityUtils. ToString (resultEntity, "utf-8");
}
EntityUtils. Consume (resultEntity);
return result;
} the catch (Exception e) {
LOGGER. The error (" HttpClient, error status code: "+ um participant etMessage ());
} the finally {
If (httpPost!=null) {
HttpPost. ReleaseConnection ();
}
If (httpClient!=null) {
Try {
HttpClient. Close ();
} the catch (IOException e) {
LOGGER. The error (" httpClient - IOException ", e);
}
}
}
return null;
}

CodePudding user response:

I look at the code under the EntityUtils. Consume () httpClient. Close () source, will close the connection, right before I guess is wrong.

CodePudding user response:

I also encountered this problem, in golang HTTP client need to use the connection pool and long connection, all in all is the need to connect the repeatable usability,
If it is of a great deal in high concurrency short connection constantly switch, can cause a lot of connections in CLOSE_WAIT state, this state will last about 4 minutes, can lead to fd resource depletion,

CodePudding user response:

Need to configure the HttpClient connection pool PoolingHttpClientConnectionManager, set the maximum number of connections, prevent the machine from resource depletion collapse, if the maximum number of connections is not satisfy the existing business, it need to consider adding machine, load balancing

CodePudding user response:

If the connection is scarce resources (slow query interface), then you may need to add a layer of buffer layer, the use of MQ in a layer of cache, so that even if you request to many, platoon line, when the connection pool has the resources to handle the request

CodePudding user response:

This post is recommended blogs have a very

https://blog.csdn.net/ciyiwa8779/article/details/100291067? Utm_medium=distribute. Pc_relevant_bbs_down. None - task - blog - baidujs - 1. Nonecase& Depth_1 - utm_source=distribute. Pc_relevant_bbs_down. None - task - blog - baidujs - 1. Nonecase

CodePudding user response:

This blog is worth a look