Connection timeouts in JEP 321 (HTTP Client)

[Simone Bordet]

Hi,

On Wed, Aug 1, 2018 at 5:10 PM Chris Hegarty <chris.hegarty at oracle.com> wrote:
> Before trying to draft the javadoc, the semantic we want for this
> overall timeout is that it should approximately related to the observed
> time spent in send[Async].

I'm not sure I agree, especially for sendAsync(), which should setup
things for sending and then immediately return.

> Ignoring connect for now, this means that
> the timer starts from the initial DNS lookup/TCP connection

Confused. You are not ignoring the connect if you take into account
DNS and TCP connection establishment.

> and ends
> when the complete request has been sent and the complete response
> has been received. This seems like the most useful overall timeout
> semantic.

Indeed.
Note that it's indeed request *and* response completion, including
data for both.
That means if the request takes longer than the response, it'll
possible trigger _after_ the complete response has arrived to the
client.

> There is a question about whether or not the response body is part
> of the timeout. It currently is not since the body handler API has the
> ability to either stream the response body or return it as a higher-level
> Java Object, e.g String, etc.

IMHO it should be. Response content is where things may go really
slow, as the HTTP response headers are typically delivered in just one
TCP frame (for both HTTP1 and HTTP2).

> I agree with adding `connectTimeout` to HttpClient.

Great.

> The low-level details
> of what constitutes a new underlying connection is somewhat known. I
> agree that it should take into account such things as DNS lookup, TCP
> connect, and SSL handshake.

As I said, I'm not sure about the latter, but either works for me.

> Summary of modes:
>
>   1) HttpRequest `timeout` only - times both connect ( if any ) and
>      until both the request and the response are fully send and received,
>      respectively.

Yes, including - for both - their respective content.

>   2) HttpClient `connectTimeout` only - times only the connect phase,
>      if any. Timer stops after connection has been established.

Yes.

>   3) HttpClient `connectTimeout` and HttpRequest `timeout` - start
>      connect phase timer at DNS lookup, stop at TCP connect finished
>      or SSL handshake complete. Start request specific timer shortly
>      after connect timer stops, i.e. just before the HTTP request is sent.
>      Stop request specific timer when both the request and the response
>      are fully send and received, respectively.

Seems to me that this contradicts what you said before (total timeout
includes the connectTimeout).

Given exchange = request+response, then:
1. send request
2. start "total" timer
3a. need to open connection, start "connectTimeout" timer and try to
open connection; if connectTimeout elapses, "total" timeout is
cancelled, and exchange is failed; if connection is opened, cancel
connectTimeout.
3b. connection available, send request.
3c. connections exist, but none is available to send (all busy with
other exchanges and cannot open a new connection due to capping of
number of connections to same origin), request is queued.
4. "total" timeout elapses, exchange can be: queued, sending or
receiving; in all cases fail the exchange.
5. exchange completes in time, cancel "total" timeout.

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz