[
https://issues.apache.org/jira/browse/HTTPCLIENT-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303680#comment-17303680
]
Carter Kozak commented on HTTPCLIENT-2143:
------------------------------------------
> How useful are all these timeouts?
Where I've found this would be most useful is for sending large requests to a
server that must store the data. In many cases even if the server is capable of
processing the data before it's all received, the request will be intercepted
by a proxy which fully buffers the request before forwarding it to an upstream
server. In these cases I want to fail if I'm unable to write a byte in ~30
seconds, the request i/o timeout, step (1), however my timeout waiting for a
response must be long enough to wait for the request data to be transferred
from a the reverse proxy to the upstream server, and for that server to begin
sending back a response (step (2)) which may take several minutes.
> Are they really worth all this extra complexity?
For me, yes, however I understand that may not be the case for everyone. I
created this ticket so that we can collectively make that decision.
> Besides I am pretty sure it is not going to work well (or easily) with
>pipelined HTTP/1.1 and multiplexed HTTP/2 exchanges.
I cannot speak to how easily it could be implemented yet, however in a
pipelined or multiplexed configuration we would want to apply timeouts to
individual write operations to a single stream rather than the underlying
connection. I think my use of the phrase "socket timeout" was not quite
correct, these would be "I/O timeouts".
> They also wouldn't work well with bidirectional streaming, where the client
>and the server are transmitting data to each other concurrently.
There are certainly cases where it would not be helpful to set additional
timeout values, I agree. However, separate read and write timeouts can be
useful for async clients even if bytes are sent and received at the same time,
it's helpful to constrain how long the client is allowed to wait without
transferring bytes in each direction.
> Support additional per-request timeout options
> ----------------------------------------------
>
> Key: HTTPCLIENT-2143
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2143
> Project: HttpComponents HttpClient
> Issue Type: New Feature
> Components: HttpClient (classic)
> Reporter: Carter Kozak
> Assignee: Carter Kozak
> Priority: Major
>
> The classic client supports a single socket timeout, however requests are
> often broken into three (or more) phases. Note that connection initialization
> is not considered in this design, it aligns to the connection/route/pool
> rather than individual requests.
> # Sending the request (request line, headers, and optionally a request body)
> # Waiting for the remote server to process the request, until the first
> response byte is received.
> # Reading the response (response line, headers, and optionally a response
> body)
> Note that this can have additional steps between (1) and (2) for
> {{Expect-Continue,}} and it's important not to set an incorrect timeout for
> {{CONNECT}} upgrades.
> Steps (1) and (3) are I/O timeouts, while (2) is generally based on the
> server processing a request and preparing to send a response. There are cases
> in which the server processes data as it's received or sent, where one might
> not wish to rely on more specific timeouts, however in the general case it is
> helpful to detect unhealthy state without waiting the maximum response
> duration.
> h3. General Proposal
> I'd like to include options in the request config for a request socket
> timeout (step 1) and response socket timeout (step 3) allowing the existing
> {{responseTimeout}} to apply to step 2. I expect this can be done in a way
> that does not have any impact unless values are configured, but will require
> careful testing.
> Looking at the code, such a change would span both httpclient and httpcore
> projects. I haven't dug into precisely how we would plumb this data to the
> HttpRequestExecutor.
> The {{RequestConfig}} type is used by both the classic and async clients,
> it's not clear if we would support this feature on the asynchronous client as
> well as the blocking client initially.
> Any and all feedback is appreciated, I'd like to build consensus on the
> feature/idea before I begin to build it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
