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