[
https://issues.apache.org/jira/browse/HTTPCLIENT-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303641#comment-17303641
]
Oleg Kalnichevski commented on HTTPCLIENT-2143:
-----------------------------------------------
[~ckozak] How useful are all these timeouts? Are they really worth all this
extra complexity? Besides I am pretty sure it is not going to work well (or
easily) with pipelined HTTP/1.1 and multiplexed HTTP/2 exchanges.
Oleg
> 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]
