#3 connection pool: expired connection checking

[Anonymous]

Connection age should be checked in the AbstractConnectionPool.getConnection method instead of releaseConnection.

Checking connection's age is one of the methods preventing to obtain invalid connection e.g. closed by firewall when connection was idle (in the pool) for considerable period of time. If connectionIsExpired was executed in the getConnection context, api client would always get fresh (and valid) connection. Otherwise errors such as:
Caused by: LDAPSearchException(resultCode=81 (server down), numEntries=0, numReferences=0, errorMessage='The connection to server host:389 was closed while waiting for a response to search request SearchRequest(baseDN='CN=Users,DC=o,DC=sk', scope=SUB, deref=NEVER, sizeLimit=1, timeLimit=0, filter='(&(sAMAccountName=ivan)(objectClass=user))', attrs={userPrincipalName, cn, givenName, sn, mail, cn}).')
at com.unboundid.ldap.sdk.SearchRequest.processSync(SearchRequest.java:1485)
are very frequent...

[Neil Wilson]

The current behavior was chosen intentionally and I believe it is the correct design. The desire is to allow access to process the request and get the response as quickly as possible, and under normal conditions even a connection that has been established for longer than the maximum connection age will still be usable.

In addition, with the LDAPConnectionPool, the connection age is periodically examined as part of the normal background health checking process, so expired connections are likely to be discovered and replaced by that process before they become unavailable. This is unfortunately not possible with the LDAPThreadLocalConnectionPool because background health checking cannot be performed for this kind of connection pool, and I'm guessing based on your description that you're using the thread-local connection pool.

However, there are other things that you can do to accomplish what you want. One option would be to create a custom health check that provides an implementation of the ensureConnectionValidForCheckout method that calls the connection's getConnectTime method and throws an exception if the connection is considered too old.

Another alternative would be to configure the connection pool to allow automatically retrying operations if they fail in a way that indicates the connection is no longer valid. You can do that using the setRetryFailedOperationsDueToInvalidConnections method. If this is enabled and the connection has become invalidated for some reason (like a firewall blocking it after a long idle time), then the failure would be caught, the connection would be closed and a new one created to take its place, and the operation would be retried on that new connection. Other than the additional time required to re-establish the connection and re-try the operation, this would be completely transparent to your code. However, it's only possible if you're performing operations in the context of the pool (e.g., using one of the pool's search methods to perform a search rather than checking out a connection and using the connection's search method).

Ultimately, the thread-local connection pool is nice because you don't have to worry about declaring a pool size, but it has some pretty significant health checking disadvantages as compared with the regular LDAPConnectionPool implementation. If you have an idea as to how many threads your application might be using, then it might be better to just use that information to size an LDAPConnectionPool.

[Anonymous]

my experience is that in many enterprise environments (e.g. telco segment) there is always some "malicious" fw rule that require connection pool tuning. in my opinion it is better to do checks before returning connection to client nevertherless the cost of response time...
however, i've found the exactl same solution you mention - custom healt check with ensureConnectionValidForCheckout implementation. since https://sourceforge.net/tracker/?func=detail&aid=3527511&group_id=275998&atid=1172442 issue is fixed, i have no other suggestions.
thank you.