Connection timeouts in JEP 321 (HTTP Client)

[Markus Ivan Peloquin]

It's unfortunate that the user sees this when a connection wasn't even 
established:
java.net.http.HttpTimeoutException: request timed out

Could it use Channel::isOpen to return a more specific exception? 
HttpConnectionException? Or at least a more specific message.

 > How important is this for 11 ...?
If the question's for me, it's a strong preference. I would prefer to 
keep my legacy code in place in order to preserve my short connection 
timeouts and the more specific SocketTimeoutException root cause. I have 
to diagnose problems using backtraces, and the lack of information makes 
it difficult. Though I may be okay with something like 
HttpConnectionException.

Markus

On 2018-07-25 07:43, Chris Hegarty wrote:
> Clearly the request builder `timeout` method can be used to avoid
> extremely long connection timeouts ( as demonstrated below ), but I see
> Bernd's call for more fine grained control over various aspects of the
> request.
>
> I'm not opposed to an "HttpRequest.Builder.connectTimeout` method, but
> this is coming very late in the JDK 11 development cycle. How important
> is this for 11, given that the naked `timeout` can be used, somewhat, to
> mitigate against long connection timeouts?
>
>
> $ cat Get.java
>
> import java.net.URI;
> import java.net.http.HttpClient;
> import java.net.http.HttpRequest;
> import java.net.http.HttpResponse;
> import java.net.http.HttpResponse.BodyHandlers;
> import java.time.Duration;
>
> public class Get {
>    public static void main(String[] args) throws Exception {
>      long before = System.nanoTime();
>      try {
>        HttpClient client = HttpClient.newHttpClient();
>        HttpRequest request = HttpRequest.newBuilder(URI.create(args[0]))
>              .timeout(Duration.ofSeconds(10))
>              .build();
>        HttpResponse<String> response = client.send(request, BodyHandlers.ofString());
>        System.out.println("response :" + response);
>      } finally {
>        System.out.println("elapsed secs :" + ((System.nanoTime() - before)/1000_000_000));
>      }
>    }
> }
> $ javac Get.java
> $ java Get http://example.com:81
> elapsed secs :10
> Exception in thread "main" java.net.http.HttpTimeoutException: request timed out
>     at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:551)
>     at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:113)
>     at Get.main(Get.java:17)
>
> -Chris.
>
>> On 24 Jul 2018, at 19:34, Markus Peloquin <markpeloquin at gmail.com> wrote:
>>
>> Somebody pointed me at the upcoming HTTP client implementation, and I'm sad to see that connection timeouts are missing from the implementation (the old HTTP API). Is the absence of connection timeouts intended or an oversight? I'd like to see it added, and it looks like a simple change to me.
>> http://openjdk.java.net/jeps/321
>> http://mail.openjdk.java.net/pipermail/jdk-dev/2018-March/000996.html
>>
>> There are some environments (such as AWS VPCs), where connection failures are only indicated by a connection timeout. This is because ICMP 'Destination Unreachable' packets are often not forwarded to the client (by load balancers, private links, etc) and there are supposedly some security concerns with allowing them by default. Those ICMP packets give immediate failures (net/host/protocol/port unreachable), but timeouts are slow.
>>
>> The default timeout is unbounded in Java, though the TCP implementation of the OS times-out connection establishment to around 130 seconds.
>>
>> It looks like the implementation uses SocketChannel, which still supports timeouts via chan.socket().connect(addr, timeout).
>>
>> Markus