[
https://issues.apache.org/jira/browse/HTTPCLIENT-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401233#comment-17401233
]
neng xu commented on HTTPCLIENT-2167:
-------------------------------------
Sorry. We are not on same page.
"share the same HTTP context or have the same user token"
1. I think HTTP Context and User Token is at HTTP layer. SSL mutual
authentication is at TLS layer.
So, they should not be mixed together when implement HTTP specs.
If you really want to use SSL certificate as userToken to maintain
authentication state (HTTP spec does not address it),
It should have follow flow
First call
this.state=null;
state=Certificate CN
Second call
this.state=Certificate CN
state=Certificate CN
2. HttpClient5 doc says "IMPORTANT: Please note HTTP context implementation,
even when thread safe, may not be used concurrently by multiple threads, as the
context may contain thread unsafe attributes."
Http Context object can be shared by Http calls which are executed by one
thread.
not shared by the HTTP Calls which are executed by multiple threads
concurrently.
> 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]
