JDK-8287062 : com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed due to different timeout message
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.naming
  • Affected Version: 11,19,21,22,24,25,26
  • Priority: P4
  • Status: In Progress
  • Resolution: Unresolved
  • Submitted: 2022-05-20
  • Updated: 2025-10-10
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
tbdUnresolved
Related Reports
Duplicate :  
JDK-8366950 - Test com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed
Duplicate :  
JDK-8350618 - Test com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed because exception message was null
Sub Tasks
JDK-8355278 :  
Improve debuggability of com/sun/jndi/ldap/LdapPoolTimeoutTest.java test - Resolved
Description
javax.naming.CommunicationException: LDAP response read timed out, timeout used: 2958 ms. [Root exception is java.io.IOException: LDAP response read timed out, timeout used: 2958 ms.]
	at java.naming/com.sun.jndi.ldap.Connection.readReply(Connection.java:468)
	at java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:368)
	at java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:195)
	at java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2895)
	at java.naming/com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:348)
	at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxFromUrl(LdapCtxFactory.java:225)
	at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:189)
	at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:243)
	at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154)
	at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84)
	at java.naming/javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:732)
	at java.naming/javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305)
	at java.naming/javax.naming.InitialContext.init(InitialContext.java:236)
	at java.naming/javax.naming.InitialContext.<init>(InitialContext.java:208)
	at java.naming/javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:130)
	at LdapPoolTimeoutTest.lambda$attemptConnect$8(LdapPoolTimeoutTest.java:119)
	at LdapTimeoutTest.lambda$assertCompletion$18(LdapTimeoutTest.java:361)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.lang.Thread.run(Thread.java:828)
Caused by: java.io.IOException: LDAP response read timed out, timeout used: 2958 ms.
	at java.naming/com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:129)
	at java.naming/com.sun.jndi.ldap.Connection.readReply(Connection.java:444)
	... 18 more

This cause message is none of the following pre-defined messages in this test,
Network is unreachable
Timed out waiting for lock
Connect timed out
Timeout exceeded while waiting for a connection
Comments
Again the recent failures, like JDK-8366950, do not seem to be a duplicate of this but rather are caused by the timeout factor change which in turn has reduced the internal timeouts used by the test. task 1 failed: java.lang.RuntimeException: After 9500 ms. (waitTime 9500 ms.) is incomplete at LdapTimeoutTest.assertCompletion(LdapTimeoutTest.java:398) at LdapPoolTimeoutTest.attemptConnect(LdapPoolTimeoutTest.java:112) at LdapPoolTimeoutTest.lambda$test$0(LdapPoolTimeoutTest.java:85) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:330) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614) at java.base/java.lang.Thread.run(Thread.java:1474)
09-10-2025
Are the recent failures, like JDK-8366950, really a duplicate of this old issue?
10-09-2025
> This failure seems similar to previous sightings that it fails with a "Network is unreachable" message. I had a look at the test code and the recent failure. I think the "Network is unreachable" message in the logs is distracting and isn't the acutal problem. Looking at the test, the test is implemented in a manner where these exceptions are expected and when they happen, the error message like this one is printed out, like in this case. The real cause of the failure is: ... MSG: null ... java.lang.AssertionError: expected [true] but found [false] at org.testng.Assert.fail(Assert.java:99) at org.testng.Assert.failNotEquals(Assert.java:1037) at org.testng.Assert.assertTrue(Assert.java:45) at org.testng.Assert.assertTrue(Assert.java:55) at LdapPoolTimeoutTest.attemptConnect(LdapPoolTimeoutTest.java:131) at LdapPoolTimeoutTest.lambda$test$6(LdapPoolTimeoutTest.java:98) Specifically, this catch block in the test: } catch (NamingException ex) { String msg = ex.getCause() == null ? ex.getMessage() : ex.getCause().getMessage(); System.err.println("MSG: " + msg); assertTrue(msg != null && (msg.contains("Network is unreachable") || msg.contains("Timed out waiting for lock") || msg.contains("Connect timed out") || msg.contains("Timeout exceeded while waiting for a connection"))); It expects the NamingException (or its cause) to have a non-null message. In the failing cases, it looks like the message is absent (the logged line MSG: null indicates that). Looking back in the comments of this issue, Mark too noted about this for a previous sighting. I am unsure what's causing the missing exception message. I think I'll propose a trivial refactor of this test to allow for the original exception stacktrace to be logged in cases like these so that we can then understand what's causing the missing exception message.
19-04-2025
we observed somethin similar in the com/sun/jndi/ldap/LdapPoolTimeoutTest.java test : MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.ConnectException: Connection timed out: no further information] MSG: Timed out waiting for lock MSG: Timed out waiting for lock MSG: Connect timed out MSG: Timed out waiting for lock MSG: Timed out waiting for lock MSG: Timed out waiting for lock MSG: Timeout exceeded while waiting for a connection: 26997ms java.lang.Exception: failures: 1 at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:104) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:840) should we allow the "ConnectException: Connection timed out" exception too ? Seme to be an issue on some of our infrastructure.
27-09-2023