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 <[email protected]> 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
