Summary

Due to the locking implementation in ldap connection pooling, the com.sun.jndi.ldap.connect.timeout property can stack where many threads are attempting to connect to an unreachable ldap endpoint. This fix proposes to change that behaviour so that all threads will timeout regardless of whether they were able to grab the connection lock or not.

Problem

An ldap context url can define multiple endpoints. In the event that the first endpoint cannot be reached, the remaining endpoints will be tried until the request succeeds. Each of these connection attempts is subject to the "com.sun.jndi.ldap.connect.timeout" property. If connection pooling is in use the locking mechanism forces multiple threads to contend for the same lock while the connection attempt is being made. Currently the connection timeout is only started once the lock has been grabbed by a thread. This means that if 10 threads were to attempt to connect to an unreachable endpoint, each thread would have to timeout individually. I.e. the last thread would be waiting for (10 x com.sun.jndi.ldap.connect.timeout)

Solution

The current synchronized block is replaced with a ReentrantLock. Any attempt to grab this lock is subject to a timeout <= com.sun.jndi.ldap.connect.timeout. If the lock has not been grabbed within the timeout the connection attempt will be timed out. In addition to this any time spent waiting for the lock is subtracted from the connection timeout once the connection attempt actually begins.

Specification

I believe this is an implementation bug and, as such, should not require any specification changes.