[
https://issues.apache.org/jira/browse/HTTPCLIENT-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17393096#comment-17393096
]
neng xu commented on HTTPCLIENT-2167:
-------------------------------------
Oleg Hi
Our application uses stateless HTTPS. The URL is F5 which load balance to our
Tomcat servers.
Our application does not keep the state.
As you see my case, when doing first call, both this.state and state are null.
My understanding is that this.state should be set with state value. (null)
When doing HTTP call, I saw this.state=null in second call. (socket is reused.
no problem)
When doing HTTPS call (normal SSL), I saw this.state=null in second call.
(socket is reused. no problem)
When doing HTTPS call (mutual SSL), I saw this.state=X500Principal object in
second call. which is not the state value of first call. Since the state value
of second call is null, socket is always closed.
If HTTP Client 5 uses Client SSL certificate as userToken, The correct way is
First call,
this.state=null
state=X500Principal object
Second call
this.state=X500Principal object
state=X500Principal object
Note: Application uses same URL and client certificate. The first call and
second call uses same ClosableHttpClient object (same route, state, sslcontext)
"Please make sure your code correctly handles connection state correctly or
disable connection state tracking if all requests executed by your application
share the same security context. "
Could you tell me how to disable connection state tracking?
Thanks
> BasicHttpClientConnectionManager always close the socket connection
> --------------------------------------------------------------------
>
> Key: HTTPCLIENT-2167
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2167
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 5.1
> Reporter: neng xu
> Priority: Major
>
> Test Case:
> Created ClosableHttpClient with BasicHttpClientConnectionManager.
> Used the ClosableHttpClient object to do two post and all successful.
> The problem is keepAlive does not work and two posts create two socket
> connections.
> The second post does not reuse the socket created by first post .
>
> Fist post
> 2021-08-03 09:48:28,291 DEBUG
> [org.apache.hc.client5.http.impl.classic.InternalHttpClient] ex-00000001:
> preparing request execution
> .....
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager]
> Connection can be kept alive for 50 SECONDS
> response code: 200
> Second post
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.impl.classic.InternalHttpClient] ex-00000002:
> preparing request execution
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.impl.classic.InternalHttpClient] ex-00000002:
> preparing request execution
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.protocol.RequestAddCookies] Cookie spec selected:
> strict
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.protocol.RequestAddCookies] Cookie spec selected:
> strict
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.protocol.RequestAuthCache] Auth cache not set in
> the context
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.protocol.RequestAuthCache] Auth cache not set in
> the context
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.impl.classic.ProtocolExec] ex-00000002: target
> auth state: UNC
> HALLENGED
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.impl.classic.ProtocolExec] ex-00000002: proxy
> auth state: UNCH
> ALLENGED
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.impl.classic.ConnectExec] ex-00000002: acquiring
> connection wi
> th route \{s}->https://ecpr-et.wellsfargo.com:4444
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.impl.classic.InternalHttpClient] ex-00000002:
> acquiring endpoi
> nt (50 SECONDS)
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager] Get
> connection for r
> oute \{s}->https://ecpr-et.wellsfargo.com:4444
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.impl.io.BasicHttpClientConnectionManager] Closing
> connection G
> RACEFUL
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.impl.io.DefaultManagedHttpClientConnection]
> http-outgoing-0: c
> lose connection GRACEFUL
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.impl.classic.InternalHttpClient] ex-00000002:
> acquired endpoin
> t InternalConnectionEndpoint-58aa1698
> 2021-08-03 09:48:28,868 DEBUG
> [org.apache.hc.client5.http.impl.classic.ConnectExec] ex-00000002: opening
> connection \{s}-
> >[https://ecpr-et.wellsfargo.com:4444|https://ecpr-et.wellsfargo.com:4444/]
> ................
> Note: Above trace showed that second post will close previous socket when
> "Get connection for route \{s}->https://ecpr-et.wellsfargo.com:4444";
> Did debug and saw the issue at follow method. of
> BasicHttpClientConnectionManager class
> synchronized ManagedHttpClientConnection getConnection(final HttpRoute route,
> final Object state) throws IOException {
> ..................
> Asserts.check(!this.leased, "Connection is still allocated");
> if (!LangUtils.equals(this.route, route) || !LangUtils.equals(this.state,
> state)) {
> closeConnection(CloseMode.GRACEFUL);
> }
> ..................
> return this.conn;
> }
> Bug is at line: "if (!LangUtils.equals(this.route, route) ||
> !LangUtils.equals(this.state, state)) {"
> For stateless HTTP call, the state is always null, LangUtils.equal() always
> returns false.
> That line is always true even first post and second post has same route.
> Therefore, it always call "closeConnection(CloseMode.GRACEFUL);" to close the
> previous socket connection although it meets keepAlive requirement.
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
