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 src/java.naming/share/classes/com/sun/jndi/ldap/pool/PooledConnectionFactory.java line 54: > 52: * @param timeout the connection timeout > 53: */ > 54: public abstract PooledConnection createPooledConnection(PoolCallback > pcb, long timeout) why not use int timeout to be consistent with existing code ? You've been required to "squash" it into an int in the factory ? ------------- PR: https://git.openjdk.java.net/jdk/pull/6568
