On Tue, 14 Dec 2021 15:26:54 GMT, Rob McKenna <r...@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
test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java line 88:
> 86: env.put("com.sun.jndi.ldap.connect.timeout",
> String.valueOf(CONNECT_MILLIS));
> 87: env.put("com.sun.jndi.ldap.connect.pool", "true");
> 88: env.put(Context.PROVIDER_URL, "ldap://example.com:1234";);
I assume this makes the assumption that requests to "example.com:1234" will
fail in timeout?
If so wouldn't it be safer to create a ServerSocket that never accepts
connections?
Otherwise looks OK to me.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6568
