[
https://issues.apache.org/jira/browse/HTTPCLIENT-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416295#comment-17416295
]
Ryan Schmitt commented on HTTPCLIENT-2135:
------------------------------------------
The problem appears to be that you're reusing the same {{Socket}}, the one
passed as the first parameter to the {{connect}} method. The retry is thus
doomed to fail, because the {{Socket}} is trashed from the previous (failed)
connection attempt. It looks like this bug was introduced by the refactoring,
since there was previously a {{Socket sock = sf.createSocket(context);}}
statement in the body of the {{for}}-loop. The {{MultihomeSocketConnector}} API
will have to be changed somehow.
> TLS handshake timeouts cannot be controlled through RequestConfig
> -----------------------------------------------------------------
>
> Key: HTTPCLIENT-2135
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2135
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 5.0.3
> Reporter: Ryan Schmitt
> Priority: Major
> Fix For: 5.2-alpha1
>
>
> Apparently as a consequence of HTTPCLIENT-2091 and/or HTTPCLIENT-2099, TLS
> handshake timeouts can no longer be specified through any of the three
> {{RequestConfig}} timeout parameters (connect, connection request, response).
> The only way to limit TLS handshake duration is through low-level socket
> configuration (socket timeout), which of course affects more than just TLS
> handshakes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
