Connection timeouts in JEP 321 (HTTP Client)

[Bernd Eckenfels]

Hello,

I think the overall request Timeout is not a good substitute (if it applies to connect or DNS at all). Typically you want a small connect Timeout to allow failover or retry and a larger request Timeout to allow long running activities.

However propagating the request Timeout (shortened) to the default connect Timeout would be an additional improvement independent from the socket connect timeout.

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: -1022778048m Auftrag von
Gesendet: Mittwoch, Juli 25, 2018 11:00 AM
An: Markus Peloquin
Cc: net-dev at openjdk.java.net
Betreff: Re: Connection timeouts in JEP 321 (HTTP Client)

Hi Markus,

The API and implementation supports an overall response timeout through the method:

HttpRequest.Builder timeout​(Duration duration)

So, I don't think any application should be required to wait for 130 seconds.
It does not currently have a timeout setting specific for connection setup though.
Maybe that is something which could be added in a future release.

- Michael.


On 24/07/2018, 19:34, Markus Peloquin 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180725/b421f3f7/attachment-0001.html>