[
https://issues.apache.org/jira/browse/HTTPCLIENT-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17302751#comment-17302751
]
Oleg Kalnichevski edited comment on HTTPCLIENT-2141 at 3/16/21, 5:57 PM:
-------------------------------------------------------------------------
> Request config timeouts are on TCP, while the retry problem is in HTTP.
[~michael-o] I made a mistake of sticking `connectTimeout` and
`connectionRequestTimeout` into {{RequestConfig}}. They should have never been
there in the first place. I also would not like to add more stuff to
{{RequestConfig}}. I would rather deprecate `connectTimeout` and
`connectionRequestTimeout` and move them to an entirely new config class. This
would also help resolve HTTPCLIENT-2135 raised by [~rschmitt].
Please note that `responseTimeout` is not TCP related and is not the same as a
socket timeout anymore. HTTP/1.1 pipelined requests and HTTP/2 requests may no
longer meddle with the underlying connection settings as they can be sharing
the same physical connection with other message exchanges.
The `responseTimeout` setting as a max limit value for retry intervals sounds
quite OK to me.
Oleg
was (Author: olegk):
> Request config timeouts are on TCP, while the retry problem is in HTTP.
[~michael-o] I made a mistake of sticking `connectTimeout` and
`connectionRequestTimeout` into {{RequestConfig}}. They should have been there
in the first place. I also would not like to add more stuff to
{{RequestConfig}}. I would rather deprecate `connectTimeout` and
`connectionRequestTimeout` and move them to an entirely new config class. This
would also help resolve HTTPCLIENT-2135 raised by [~rschmitt].
Please note that `responseTimeout` is not TCP related and is not the same as a
socket timeout anymore. HTTP/1.1 pipelined requests and HTTP/2 requests may no
longer meddle with the underlying connection settings as they can be sharing
the same physical connection with other message exchanges.
The `responseTimeout` setting as a max limit value for retry intervals sounds
quite OK to me.
Oleg
> DefaultHttpRequestRetryStrategy has no timeout on retryafter header
> -------------------------------------------------------------------
>
> Key: HTTPCLIENT-2141
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2141
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 5.0.3
> Reporter: Pierre N.
> Priority: Major
>
> In *DefaultHttpRequestRetryStrategy.java:207* value of the HTTP retry header
> of the failed server is reused as is by *HttpRequestRetryExec:143* to sleep
> the thread.
> A server returning a very far retry after header is able to block httpclient
> request indefinetly by default (and even if proper connect, connection and
> response timeouts have been set).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
