[
https://issues.apache.org/jira/browse/HTTPCLIENT-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303607#comment-17303607
]
Carter Kozak commented on HTTPCLIENT-2143:
------------------------------------------
Let me make sure I understand your question correctly: Are you asking if (2) is
covered by (3) combined with polling/reading the response stream? I don't think
that's quite the same because I may expect the server to process my request for
~30 seconds, but once it begins to send data I expect a ~1 second timeout to be
more than adequate, and fail if read operations take longer.
I fear I may have misinterpreted the question though, there may be existing
{{readTimeout}} and {{poll}} options that I'm not familiar with.
> 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]
