Bug ID: JDK-8261895 java/net/URLPermission/nstest/LookupTest fails with unexpected UnknownHostException

JDK-8261895 : java/net/URLPermission/nstest/LookupTest fails with unexpected UnknownHostException

Type: Bug
Component: core-libs
Sub-Component: java.net
Affected Version: 17

Priority: P4
Status: Resolved
Resolution: Duplicate

Submitted: 2021-02-17
Updated: 2021-02-23
Resolved: 2021-02-23

Versions (Unresolved/Resolved/Fixed)

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.

Other
tbd inapplicableResolved

Related Reports

Duplicate :

JDK-8262195 - Harden tests that use the HostsFileNameService (jdk.net.hosts.file property)

Description

java/net/URLPermission/nstest/LookupTest.java test fails to resolve allowedAndFound.com host:

Connecting to http://allowedAndFound.com:36679/foo
Unexpected IOException:allowedAndFound.com
java.lang.RuntimeException: java.net.UnknownHostException: allowedAndFound.com
	at LookupTest.test(LookupTest.java:82)
	at LookupTest.main(LookupTest.java:123)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:831)
Caused by: java.net.UnknownHostException: allowedAndFound.com
	at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:567)
	at java.base/java.net.Socket.connect(Socket.java:631)
	at java.base/java.net.Socket.connect(Socket.java:581)
	at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:182)
	at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:497)
	at java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:600)
	at java.base/sun.net.www.http.HttpClient.<init>(HttpClient.java:246)
	at java.base/sun.net.www.http.HttpClient.New(HttpClient.java:351)
	at java.base/sun.net.www.http.HttpClient.New(HttpClient.java:372)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1299)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1266)
	at java.base/sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1110)
	at java.base/sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1108)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
	at java.base/java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:934)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1107)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:1051)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1653)
	at java.base/sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1569)
	at java.base/sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1567)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
	at java.base/java.security.AccessController.doPrivilegedWithCombiner(AccessController.java:934)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1566)
	at LookupTest.test(LookupTest.java:73)
	... 7 more

The test uses hosts file name service to resolve addresses, therefore it doesn't look like a temporary DNS resolution issue.

Comments

Issue has been grouped with other similar failures at this link. Thanks for spotting that I was missing the link [~dcubed]!
23-02-2021
These tests seems to be setting the jdk.net.hosts.file property programmatically in the main. I wonder if something could be triggering the loading of the InetAddress class too early for seeing the value of the system property. I can't explain why it would be intermittent though.
17-02-2021
Right. If the writes were not flushed from the Java Print/FileWriter before use, then that might be a problem, but they are closed in the addMappingToHostsFile method, which should guarantee they are flushed. Even if the OS has not flushed to disk, reads should still be correct from the buffer cache. We need to check what if any changes there has been to the jdk.net.hosts.file mechanism itself.
17-02-2021
Similar failures as shown in JDK-8261915. Not sure what the comment above on "flush to disk" means, but in the two tests (Test.java and ExtensionsWithLDAP.java), the jdk.net.hosts.file are static and not generated at runtime.
17-02-2021
That looks like a reasonable explanation to me. With 'allowedAndFound.com' removed from the host file generation method [1], the test is failing with the same exception: Connecting to http://allowedAndFound.com:43273/foo Unexpected IOException:allowedAndFound.com java.lang.RuntimeException: java.net.UnknownHostException: allowedAndFound.com at LookupTest.test(LookupTest.java:82) at LookupTest.main(LookupTest.java:123) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) [1] change to remove 'allowedAndFound.com' from generated host file: +// addMappingToHostsFile("allowedAndFound.com", +// InetAddress.getLoopbackAddress().getHostAddress(), +// hostsFileName, +// false);
17-02-2021
may be the mappings to the host file hadn't been flushed to disk, by the time the test attempted to read them. Does a (auto)close of PrintWriter (or close of a linux file at the OS level) guarantee that its data has been written to disk? Could the data remain pending in its file buffer cache for a time after the close? perhaps invoking hfPWriter.flush() in the add mapping method would ensure the update is written to disk?
17-02-2021