RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3]

[Aleksei Efimov]

On Tue, 14 Dec 2021 15:26:54 GMT, Rob McKenna <robm at openjdk.org> wrote:

>> This fix attemps to resolve an issue where threads can stack up on each other while waiting to get a connection from the ldap pool to an unreachable server. It does this by having each thread start a countdown prior to holding the pools' lock. (which has been changed to a ReentrantLock) Once the lock has been grabbed, the timeout is adjusted to take the waiting time into account and the process of getting a connection from the pool or creating a new one commences.
>> 
>> Note: this fix also changes the meaning of the connection pools initSize somewhat. In a situation where we have a large initSize and a small timeout the first thread could actually exhaust the timeout before creating all of its initial connections. Instead this fix simply creates a single connection per pool-connection-request. It continues to do so for subsequent requests regardless of whether an existing unused connection is available in the pool until initSize is exhausted. As such it may require a CSR.
>
> Rob McKenna has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow the test to pass on MacOSX

The changes look good to me.
Few minor comments:
The last modification year in copyright headers can be updated.

test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java line 29:

> 27:  *          lib/
> 28:  * @run testng/othervm LdapPoolTimeoutTest
> 29:  * @bug JDK-8277795

I believe the `JDK-` prefix is not needed in `@ bug` tag value.
Tags can be also reordered to follow the recommendations [here](https://openjdk.java.net/jtreg/tag-spec.html#ORDER).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6568