[
https://issues.apache.org/jira/browse/HTTPCLIENT-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825776#comment-17825776
]
Oleg Kalnichevski commented on HTTPCLIENT-2324:
-----------------------------------------------
[~tndavid...@gmail.com] Again, socket timeout is _NOT_ a deadline. It ensures
that the connection socket cannot be inactive longer that the value of timeout
at {_}a point of time{_}. In other words, if the socket timeout is N and the
server sends a packet every N - 1, the connection _never_ times out. Never. At
all.
Do you know how many packets get exchanged between the local and the remote
endpoint during the TLS handshake? How many DNS queries get performed? Are
there any automatic retries or redirects?
Basically your expectations are wrong. Socket timeout value of 16 seconds does
not guarantee a socket timeout exception immediately after 16 seconds of
execution time. What it guarantees is that a single i/o operation cannot take
longer than 16 seconds.
Oleg
> Apache HttpClient 5 blocks for double the duration set by requestTimeout when
> using TLS
> ---------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-2324
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2324
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 5.3.1
> Environment: OpenJDK Runtime Environment Corretto-17.0.8.7.1
> Reporter: Tim Davidson
> Priority: Minor
>
> I have an issue in my application using Spring's RestTemplate configured with
> Apache HttpClient 5 as the underlying http client. My application is calling
> a downstream legacy system, and while that system is "down" for maintenance,
> it still accepts connections (TLS handshake and all), but never returns a
> response.
> The problem I'm having is when I set the request timeout at 8 seconds on the
> Apache client, requests sent to this downstream service are blocking for
> double that timeout setting (16 seconds).
> I have this isolated to the Apache HttpClient, and have reproduced this
> behavior in a unit test using self-signed certs. Since the code necessary to
> reproduce is too long to post here, I have a repository with the test
> reproducing the issue here:
> [apache-httpclient-socket-timeout-test|https://github.com/tndavidson/apache-httpclient-socket-timeout-test]
> You can see in the following logs that the read timeout does happen after the
> configured 8 seconds, but it is blocking for an additional 8 seconds to close
> the connection. This doesn't happen using HTTP, only HTTPS.
> {code:java}
> 14:45:21.587 [main] DEBUG org.apache.hc.client5.http.wire -- http-outgoing-1
> >> "[\r][\n]"
> 14:45:29.589 [main] DEBUG org.apache.hc.client5.http.wire -- http-outgoing-1
> << "[read] I/O error: Read timed out"
> 14:45:29.589 [main] DEBUG o.a.h.c.h.i.i.DefaultManagedHttpClientConnection --
> http-outgoing-1 Close connection
> 14:45:37.591 [main] DEBUG o.a.h.c.h.i.c.InternalHttpClient --
> InternalConnectionEndpoint-7eb6b6b6 endpoint closed {code}
> I've included two additional tests that show this issue is 1) not present
> when not configured for TLS, and 2) not present when configuring the same TLS
> configuration using the JDK's native HttpClient.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
