On Thu, 24 Sep 2020 23:46:47 GMT, Aleksei Efimov <[email protected]> wrote:
>> Hi, >> >> Please help to review >> [JDK-8251188](https://bugs.openjdk.java.net/browse/JDK-8251188) fix which >> helps to improve LDAP >> tests stability. The list of changes: 1. Usages of wildcard address have >> been replaced with loopback address. This >> change includes addition of `LDAPTestUtils.initEnv` method that takes LDAP >> provider URL as a parameter. 2. >> `DeadServerTimeoutSSLTest.java` was also updated to fix the intermittent >> failures reported by [JDK-8152654 >> ](https://bugs.openjdk.java.net/browse/JDK-8152654) and >> [JDK-8169942](https://bugs.openjdk.java.net/browse/JDK-8169942). Before the >> fix the failure rate was 1 out of 4 runs. >> After the fix it was executed 400+ times alongside to other LDAP tests, and >> showed no failures, and therefore removed >> from the problem list. Thank you, Aleksei > > Aleksei Efimov has updated the pull request incrementally with one additional > commit since the last revision: > > Update DeadServerTimeoutSSLTest to track and analyze client connections Marked as reviewed by dfuchs (Reviewer). test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java line 193: > 191: if (acceptedSocket.getLocalPort() == > clientSideSocket.getPort() && > 192: acceptedSocket.getPort() == > clientSideSocket.getLocalPort() && > 193: > acceptedSocket.getInetAddress().equals(clientSideSocket.getLocalAddress())) { Oh - sorry about that - I didn't realize checking the client socket would be so complex. This is not obvious, but of course the socket on the server side could be accepted before the connect() call from the client side returns. And anyway the LDAP stack can/will create an unconnected socket and connect it later, so placing a trigger (CountDownLatch) in the custom socket factory might not work as it might trigger too early. Hence the waiting loop :-( ... Good job here - I wish there had been a simpler way to do this! ------------- PR: https://git.openjdk.java.net/jdk/pull/252
