[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372903#comment-17372903
 ] 

Jan Peter Stotz edited comment on HTTPCLIENT-2165 at 7/1/21, 3:53 PM:
----------------------------------------------------------------------

[~olegk] Thanks for the link. I wasn't aware that httpclient internally saves 
the state of a connection but fails to apply it without a context. This fact is 
also not mentioned in the JavaDoc of PoolingHttpClientConnectionManager - 
wouldn't it be good to mention there? Also a link to HttpClientBuilder 
.disableConnectionState would be good because if you don't know what to search 
for you never find this. 

JavaDoc of HttpClientBuilder .disableConnectionState is not understandable by 
anyone who does not know the exact consequences.

In my opinion the whole system is kind of strange, httpclient saves by default 
the state of connections but does not enforce using a context that is required 
for reusing the created connections. Looks to me like an inconsistent default 
behavior a lot people run into. 

 

But that still does not explain why connections are not reused using hc5.1. The 
sample code I used bases on 
[https://github.com/apache/httpcomponents-client/blob/5.1.x/httpclient5/src/test/java/org/apache/hc/client5/http/examples/ClientCustomSSL.java]
 and it does use a context. But in that case the connections were not reused at 
all, they were not returned to the pool at all... 

Even is I call disableConnectionState connections are not reused.

 


was (Author: jbug):
[~olegk] Thanks for the link. I wasn't aware that httpclient internally saves 
the state of a connection but fails to apply it without a context. This fact is 
also not mentioned in the JavaDoc of PoolingHttpClientConnectionManager - 
wouldn't it be good to mention there? Also a link to HttpClientBuilder 
.disableConnectionState would be good because if you don't know what to search 
for you never find this. 

In my opinion the whole system is kind of strange, httpclient saves by default 
the state of connections but does not enforce using a context that is required 
for reusing the created connections. Looks to me like an inconsistent default 
behavior a lot people run into. 

 

But that still does not explain why connections are not reused using hc5.1. The 
sample code I used bases on 
[https://github.com/apache/httpcomponents-client/blob/5.1.x/httpclient5/src/test/java/org/apache/hc/client5/http/examples/ClientCustomSSL.java]
 and it does use a context. But in that case the connections were not reused at 
all, they were not returned to the pool at all... 

Even is I call disableConnectionState connections are not reused.

 

> TCP connections are never reused when server requires TLS cert auth
> -------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-2165
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2165
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient (classic)
>    Affects Versions: 4.5.13
>         Environment: Windows, OpenJDK 11
>            Reporter: Jan Peter Stotz
>            Priority: Major
>         Attachments: hc5_testcode.txt
>
>
> While performing test with an non-public web server serving a REST service I 
> noticed that Apapche commons httpclient does not reuse connections in case 
> the server requires HTTPS authentication via client certificate. 
> This is my code for initializing the ConnectionManager. The used sslContext 
> is created using the appropriate trust- and keyStore and 
> X509ExtendedKeyManager implementation.
> {{SSLConnectionSocketFactory factory = new 
> SSLConnectionSocketFactory(sslContext, hostNameVerifier);}}
> {{Registry<ConnectionSocketFactory> socketFactoryRegistry = 
> RegistryBuilder.<ConnectionSocketFactory> create().register("https", 
> factory).build();}}
> {{connManager = new 
> PoolingHttpClientConnectionManager(socketFactoryRegistry);}}
> {{connManager.setMaxTotal(1000);}}
> {{connManager.setDefaultMaxPerRoute(200);}}
> {{connManager.setValidateAfterInactivity(20000);}}{{SocketConfig socketConfig 
> = SocketConfig.custom().setTcpNoDelay(true).setSoKeepAlive(true).build();}}
> {{connManager.setDefaultSocketConfig(socketConfig);}}
>  
> {{The used server is an Undertow instance configured to require SSL client 
> authentication: setSocketOption(Options.SSL_CLIENT_AUTH_MODE, 
> SslClientAuthMode.REQUIRED)}}
>  
> {{If I disable the client auth mode requirement httpclient just opens up one 
> TCP connection to the server. If I enable https client authentication 
> httpclient opens up to the configured route maximum (200) TCP connections to 
> the server. I observed the same behavior using a different web server 
> implementation.}}
> {{Enabling logging for PoolingHttpClientConnectionManager I can see that 
> httpclient is using the full maximum of 200 connections per route if HTTPS 
> client auth is required by the server (log after making ~1000 HTTP 
> requests):}}
>  
> {{No HTTPS client auth required by server:}}
> {{DEBUG o.a.h.i.c.PoolingHttpClientConnectionManager - Connection request: 
> [route: \{s}->https://localhost:9003][total available: 1; route allocated: 1 
> of 200; total allocated: 1 of 1000]}}
>  
> {{HTTPS Client auth required by server:}}
>  {{DEBUG o.a.h.i.c.PoolingHttpClientConnectionManager - Connection request: 
> [route: \{s}->https://localhost:9003][total available: 200; route allocated: 
> 200 of 200; total allocated: 200 of 1000]}}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to