First of all, the sample test application is not cleaning-up the resources at every exit point.
The method authenticateUsingContext() returns without closing the contexts/NamingEnumeration at certain return points.
With this correction made to the sample test application, there are still connections that are left open after full clean up by the application.
To isolate the problem, I ran the test by disabling the connection pooling, and all the connections are closed properly.
I will continue investigation with cleaning up of resources when connection pooling is enabled.
Also, my testing has been with SSL enabled, I haven't tried with plain connection.
There seems to be a problem with the cleaning up of pooled
resources in the LDAP provider. This problem is intermittant
and mostly won't be seen when the number of connections are fewer.
Another factor that has a direct influence on it
is the idle timeout of pooled connections (set through com.sun.jndi.ldap.connect.pool.timeout system property). If the idle
timeout is larger (in the sample test program, it's 5 minutes),
the problem is likely to occur.
The large number of connections and the longer idle timeout for
connections leads to accumulation of resource forcing the
GC to reclaim the resources, which affects the way the
cleaning is done by the LDAP provider pooling mechanism (ideally it shouldn't,
and that is the fix to be added).
Using a smaller idle timeout (might) help in reducing the
number of open connections. However, it may not totally eradicate
the problem. A smaller idle timeout enables frequent closing
out of the idle connections that have been idle beyond the threshold
time limit, there by keeping the overall resources under control.
The fix for this will be provided in tiger release. For the fix to be made available in 1.4.2, the bug needs to be escalated.