[
https://issues.apache.org/jira/browse/HTTPCLIENT-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17414602#comment-17414602
]
Ryan Schmitt edited comment on HTTPCLIENT-2135 at 9/13/21, 9:48 PM:
--------------------------------------------------------------------
[~olegk] The intention is to fall back on the {{connectTimeout}} when the
{{handshakeTimeout}} is not specified, right? This fallback logic appears to
work for the classic client, but not the async client. The async client seems
to wait forever for the handshake to finish.
Meanwhile, on the classic client, I noticed that this connection timeout is
being reported as a socket timeout, which then confuses our error handling (we
report the error as a regular HTTP timeout, not as a connection timeout).
{code:java}
Caused by: java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:607)
at
org.apache.hc.client5.http.socket.PlainConnectionSocketFactory.lambda$connectSocket$0(PlainConnectionSocketFactory.java:85)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.hc.client5.http.socket.PlainConnectionSocketFactory.connectSocket(PlainConnectionSocketFactory.java:84)
at
org.apache.hc.client5.http.impl.io.MultihomeSocketConnector.connect(MultihomeSocketConnector.java:70)
at
org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:131)
at
org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:418)
at
org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:159)
at
org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:169)
at
org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:136)
at
org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at
org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:166)
at
org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at
org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:96)
at
org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at
org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:179)
at
org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:75)
{code}
I haven't had a chance yet to dig in to either of these issues and figure out
exactly what is causing them. I also haven't had a chance to migrate to the new
{{handshakeTimeout}} and connection-layer configuration and see how it works.
was (Author: rschmitt):
[~olegk] The intention is to fall back on the {{connectTimeout}} when the
{{handshakeTimeout}} is not specified, right? This fallback logic appears to
work for the classic client, but not the async client.
Meanwhile, on the classic client, I noticed that this connection timeout is
being reported as a socket timeout, which then confuses our error handling (we
report the error as a regular HTTP timeout, not as a connection timeout).
{code}
Caused by: java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:607)
at
org.apache.hc.client5.http.socket.PlainConnectionSocketFactory.lambda$connectSocket$0(PlainConnectionSocketFactory.java:85)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.hc.client5.http.socket.PlainConnectionSocketFactory.connectSocket(PlainConnectionSocketFactory.java:84)
at
org.apache.hc.client5.http.impl.io.MultihomeSocketConnector.connect(MultihomeSocketConnector.java:70)
at
org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:131)
at
org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:418)
at
org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:159)
at
org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:169)
at
org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:136)
at
org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at
org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:166)
at
org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at
org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:96)
at
org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at
org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:179)
at
org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:75)
{code}
I haven't had a chance yet to dig in to either of these issues and figure out
exactly what is causing them. I also haven't had a chance to migrate to the new
{{handshakeTimeout}} and connection-layer configuration and see how it works.
> 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: [email protected]
For additional commands, e-mail: [email protected]
