On Thu, 2018-11-15 at 15:23 -0800, Ryan Schmitt wrote:
> Actually, there may be *several* problems with implementing
> connection
> timeouts in terms of socket timeouts. The first problem is that the
> connection timeout may not be honored correctly (i.e. it can be
> exceeded); the second problem is that the connection timeout and the
> socket timeout proper might not actually be independently
> configurable. I was reviewing some code I have that configures a
> synchronous Apache client, and I realized that I'm calling
> `PoolingHttpClientConnectionManagerBuilder#setDefaultSocketConfig` in
> order to configure a TLS handshake timeout. There's a comment
> assuring
> me that this timeout *only* applies to connection initialization and
> not request execution, but really either behavior is surprising.
> 
> TLS handshake timeouts have been discussed previously here:
> 
> https://issues.apache.org/jira/browse/HTTPCLIENT-1478
> 
> On Thu, Nov 15, 2018 at 12:29 PM Ryan Schmitt <rschm...@pobox.com>
> wrote:
> > 
> > It very well may come down to documentation for the most part,
> > although I am curious what you think about the problems associated
> > with implementing connection timeouts in terms of socket timeouts.
> 

I personally do not see a problem here. Connect timeout is not much
different than socket timeout. It is not an absolute value that defines
a deadline for the operation. Like the socket timeout, which represents
the maximum period of time between receipt of two consecutive IP
packets, the connect timeout represents a maximum period of inactivity
between two consecutive operations. For instance HttpClient will
attempt to connect to all available DNS addresses for multi-home DNS
entries which effectively makes the deadline for the connect operation
equal n * connectTimeout (where n is the number of IP addresses for the
DNS entry).

Oleg    


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to