You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (Jira)" <ji...@apache.org> on 2021/08/18 16:22:00 UTC

[jira] [Comment Edited] (HTTPCLIENT-2167) BasicHttpClientConnectionManager always close the socket connection

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

Oleg Kalnichevski edited comment on HTTPCLIENT-2167 at 8/18/21, 4:21 PM:
-------------------------------------------------------------------------

[~neng1998] As I already tried explaining to you more than once, one needs to make sure that related message exchanges share the same HTTP context or have the same user token. If you execute the second call correctly, its state is going to be set to the client certificate CN and the persistent connection with the same state kept alive in the pool will be re-used.

Oleg


was (Author: olegk):
[~neng1998] As I already tried explaining to you more than once, one needs to make sure that related message exchanges share the same HTTP context or have the same user token. If you execute the second call correctly, its state is going to be set to the client certificate CN and the perssitent state-ful connection kept alive in the pool will be re-used.

Oleg

> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org