[jira] [Commented] (HTTPCLIENT-2324) Apache HttpClient 5 blocks for double the duration set by requestTimeout when using TLS
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Commented] (HTTPCLIENT-2324) Apache HttpClient 5 blocks for double the duration set by requestTimeout when using TLS
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825748#comment-17825748
]
Tim Davidson commented on HTTPCLIENT-2324:
--
[~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
[jira] [Commented] (HTTPCLIENT-2324) Apache HttpClient 5 blocks for double the duration set by requestTimeout when using TLS
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825714#comment-17825714
]
Oleg Kalnichevski commented on HTTPCLIENT-2324:
---
[~tndavid...@gmail.com] Are you sure your expectations are correct? A socket
timeout represents the maximum period of inactivity between two consecutive i/o
operations, not a deadline in absolute terms.
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
