JDK-8295777 : java/net/httpclient/ConnectExceptionTest.java should not rely on system resolver
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.net
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-10-21
  • Updated: 2023-01-08
  • Resolved: 2022-10-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 17 JDK 20
11.0.19-oracleFixed 17.0.7-oracleFixed 20 b21Fixed
Related Reports
Relates :  
JDK-8294723 - Review running times of tier 2 library regression tests
Description
The test verifies that the HttpClient throws a ConnectException in response to DNS resolution failures. If the DNS server is unresponsive, the test may take a long time.
We can configure Java to use a non-existent hosts file for name resolution; this way the negative DNS responses will always be available immediately.
Comments
If we look at this fix a little deeper, some questions arise as to how effective and efficient the call flow is. When you look at from whence the ConnectException comes, it is right down in the bowls of the call flow when a connection attempt is made. For this to happen a sizable amount of HttpClient framework has been instantiated and many many microseconds of processing have been expended in executing the call. java.lang.Exception: Stack trace at java.base/java.lang.Thread.dumpStack(Thread.java:2198) at java.base/sun.nio.ch.SocketChannelImpl.checkRemote(SocketChannelImpl.java:839) at java.base/sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:867) at java.net.http/jdk.internal.net.http.PlainHttpConnection.lambda$connectAsync$1(PlainHttpConnection.java:208) at java.base/java.security.AccessController.doPrivileged(AccessController.java:571) at java.net.http/jdk.internal.net.http.PlainHttpConnection.connectAsync(PlainHttpConnection.java:210) at java.net.http/jdk.internal.net.http.AsyncSSLConnection.connectAsync(AsyncSSLConnection.java:56) at java.net.http/jdk.internal.net.http.Http2Connection.createAsync(Http2Connection.java:380) at java.net.http/jdk.internal.net.http.Http2ClientImpl.getConnectionFor(Http2ClientImpl.java:130) at java.net.http/jdk.internal.net.http.ExchangeImpl.get(ExchangeImpl.java:94) at java.net.http/jdk.internal.net.http.Exchange.establishExchange(Exchange.java:369) at java.net.http/jdk.internal.net.http.Exchange.responseAsyncImpl0(Exchange.java:553) at java.net.http/jdk.internal.net.http.Exchange.responseAsyncImpl(Exchange.java:406) at java.net.http/jdk.internal.net.http.Exchange.responseAsync(Exchange.java:398) at java.net.http/jdk.internal.net.http.MultiExchange.responseAsyncImpl(MultiExchange.java:409) at java.net.http/jdk.internal.net.http.MultiExchange.lambda$responseAsync0$2(MultiExchange.java:342) at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150) at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:510) at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1773) at java.net.http/jdk.internal.net.http.HttpClientImpl$DelegatingExecutor.execute(HttpClientImpl.java:173) at java.base/java.util.concurrent.CompletableFuture.completeAsync(CompletableFuture.java:2719) at java.net.http/jdk.internal.net.http.MultiExchange.responseAsync(MultiExchange.java:295) at java.net.http/jdk.internal.net.http.HttpClientImpl.sendAsync(HttpClientImpl.java:940) at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:832) at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:133) at ConnectExceptionTest.testSynchronousPOST(ConnectExceptionTest.java:107) It would seem more reasonable that checkURI in the HttpRequestBuilderImpl, asserts whether the host is resolvable of not and stop the processing at that juncture. Thus a HttpRequest contains a host which has a reasonable chance of a connection ? public HttpRequestBuilderImpl(URI uri) { requireNonNull(uri, "uri must be non-null"); checkURI(uri); this.uri = uri; this.headersBuilder = new HttpHeadersBuilder(); this.method = "GET"; // default, as per spec this.version = Optional.empty(); } static void checkURI(URI uri) { String scheme = uri.getScheme(); if (scheme == null) throw newIAE("URI with undefined scheme"); scheme = scheme.toLowerCase(Locale.US); if (!(scheme.equals("https") || scheme.equals("http"))) { throw newIAE("invalid URI scheme %s", scheme); } if (uri.getHost() == null) { throw newIAE("unsupported URI %s", uri); } // CHECK THAT THE HOST IS RESOLVABLE HERE ?? }
24-10-2022
Changeset: 65c84e0c Author: Daniel Jeliński <djelinski@openjdk.org> Date: 2022-10-24 06:08:40 +0000 URL: https://git.openjdk.org/jdk/commit/65c84e0cf890df2a604ac07213327be007227e77
24-10-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10811 Date: 2022-10-21 09:54:13 +0000
21-10-2022