[
https://issues.apache.org/jira/browse/HTTPCLIENT-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825748#comment-17825748
]
Tim Davidson edited comment on HTTPCLIENT-2324 at 3/12/24 5:32 PM:
-------------------------------------------------------------------
[~olegk] I understand what a socket timeout represents. The problem I see is
that whatever value I set the timeout to, the client always blocks for double
that value. For instance, set this value to 16, it blocks for 32 seconds. If
this is readTimeout's expected behavior, I need to be able to explain what is
being written on that socket that creates a second readTimeout timer, so to
speak. I'm not seeing anything in the logs other than what is there above in
the code block. If the client consistently blocks for double the time of the
read timeout value, is there a different property I can to set that will ensure
my client returns in a reasonable (not double) amount of time? Lowering the
timeout below 8 sec is not feasible in my use case because the legacy service
I'm calling averages 5-7 seconds response time.
was (Author: JIRAUSER304583):
[~olegk] I understand what a socket timeout represents. The problem I see is
that whatever value I set the timeout to, the client always blocks for double
that value. For instance, set this value to 16, it blocks for 30 seconds. If
this is readTimeout's expected behavior, I need to be able to explain what is
being written on that socket that creates a second readTimeout timer, so to
speak. I'm not seeing anything in the logs other than what is there above in
the code block. If the client consistently blocks for double the time of the
read timeout value, is there a different property I can to set that will ensure
my client returns in a reasonable (not double) amount of time? Lowering the
timeout below 8 sec is not feasible in my use case because the legacy service
I'm calling averages 5-7 seconds response time.
> 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
