[
https://issues.apache.org/jira/browse/HTTPCLIENT-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17393110#comment-17393110
]
neng xu commented on HTTPCLIENT-2167:
-------------------------------------
Thank you again.
I am sorry that I cannot agree with you.
I think HTTP Client 5 treats Client certificate as a user token, but it did not
handle it properly.
This problem happened when our Application migrating HttpClient 3 to HttpClient
5.
Our Application does not have this problem with HttpClient 3.
In fact, we does not have the problem with Java Http either.
I spent many hours on this issue and tried to resolve this problem by doing
correct HTTP client 5 configuration. I have read every line of the doc in
Apache Web page and could not find a solution.
By reading Apache code, I find a way to go around the problem as following
final URL _url= new URL(.....)
final HttpClientContext context = HttpClientContext.create();
context.setUserToken(_url);
try (CloseableHttpResponse response =
this._httpclient.execute(httpPost,context)) {
HttpEntity respEntity =
response.getEntity();
rspCode=response.getCode();
respStr =
EntityUtils.toString(response.getEntity());
EntityUtils.consume(respEntity);
}
First call
this.state=null
state=URL (object)
Second call
this.state=URL (object)
state=URL (object)
It works. But I think it just covers the issue of HttpClient 5
Ed Xu
Enterprise Business Services Technology (EBST)-ECPR
> 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]
