Ralph Carlson created HTTPCLIENT-1739:
-----------------------------------------
Summary: repeated calls to HttpClients.custom.build take longer
over time
Key: HTTPCLIENT-1739
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1739
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpClient
Affects Versions: 4.5.2
Environment: windows xp 32 bit, windows 7 64 bit and RedHat enterprise
7. Tested on Web Server apache-tomee-plus-1.7.1/apache-tomee-plus-1.7.4
deployed as @Webservice's calling external webservices using httpclient
Reporter: Ralph Carlson
Priority: Minor
(Tested on latest version and version 4.3 and both have same issue.)
repeated calls to HttpClients.custom.build take longer over time. Tested using
http library in webservice that calls and outside webservice. Initially
HttpClients.custom.build run quickly for first several hundred, then takes
increasingly longer to create client despite all objects clean up as per api
spec each request. Some cache or code in the api takes longer and longer to
create the client and no api methods exposed that can change this, only
solution now was to create a Map to cache HttpClients so not creating new ones
and look up HttpClient you need based on input parameters.
sample code that when called over and over again creates the issue:
{code:java}
protected static CloseableHttpClient
_getCloseableHttpClient(HttpClientToolsInput input) throws Exception
{ //method
//--------------- you can cache these object as static final
since never change and still get the same result , included here as example
code for bug
SSLContextBuilder sslContextBuilder =
SSLContexts.custom();
sslContextBuilder.loadTrustMaterial(null, new
TrustStrategy()
{
public boolean
isTrusted(X509Certificate[] chain, String authType) throws CertificateException
{ return true; }
@Override public boolean
isTrusted(java.security.cert.X509Certificate[] chain,String authType) throws
CertificateException { return true; }
});
SSLContext sslContext = sslContextBuilder.build();
SSLConnectionSocketFactory sslConnectionSocketFactory =
new SSLConnectionSocketFactory( sslContext, new String[] {"TLSv1", "TLSv1.1",
"TLSv1.2"},null,new HostnameVerifier()
{
public void verify(String host,
X509Certificate cert) throws SSLException { }
@Override public boolean verify(String s,
SSLSession sslSession) {
return true;
}
});
Registry<ConnectionSocketFactory> socketFactoryRegistry
=
RegistryBuilder.<ConnectionSocketFactory> create().register("http",
PlainConnectionSocketFactory.INSTANCE).register("https",
sslConnectionSocketFactory).build();
SSLConnectionSocketFactory sslsf = new
SSLConnectionSocketFactory(sslContextBuilder.build());
//--------------- you can cache these object as static final :
end
//--------------- these objects below are created and
clean up each request
BasicHttpClientConnectionManager cm = new
BasicHttpClientConnectionManager(socketFactoryRegistry);
RequestConfig defaultRequestConfig =
RequestConfig.custom().setSocketTimeout(
input.getSocketTimeout()).setConnectTimeout(
input.getConnectionTimeout()).setConnectionRequestTimeout(
input.getConnectionRequestTimeout()).build();
// ---------------- get same bug if modify code to use
different client other than CloseableHttpClient
// ---------------- the .build() method takes longer
and longer to build each cycle
CloseableHttpClient httpclient =
HttpClients.custom().setConnectionManager(cm)
.setDefaultRequestConfig(defaultRequestConfig)
.setSSLSocketFactory(sslsf)
.setDefaultCredentialsProvider(credsProvider).setSSLHostnameVerifier ( new
NoopHostnameVerifier() ).build();
<rest of code to make call - non relevant to
bug>
<cleanup code - non relevant to bug>
} //method
{code:java}
this HttpClient.customer().build() method should take roughly same amount of
time to return object despite how many objects it created previously, now with
enough runs it can take minutes to return object(s)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]