I noticed while using an LDAP connect pool that calling close()
on the context did not appear to return it to the pool, despite the documentation saying otherwise. Thus when I attempt to get an item from the pool when it is already at its max size, it hangs.
I managed to narrow it down to a minimal case. Even though I believe I'm calling close()
on all of the relevant objects deterministically, it seems to rely on garbage collection to actually return objects to the pool, which is unexpected. Why is this happening? Is there some other object I should be closing?
In the code snippet below:
DirContext
from the pool (line (2)), attempt to return it to the pool (line (4)), then get another one from the pool (line (6)) which ought to return the same, returned object.Object.wait()
. I'm guessing it's waiting for a pooled object to become available.SearchResults.next()
- it works fine.Since commenting out line (3) makes the problem go away, perhaps I'm not closing the return value of it correctly, and it's holding the pooled connection open. However, the method results.next()
returns a SearchResult
in this case, which has no close
method and no guidance in its documentation on how to close it cleanly.
The test case:
@Test
public void testHangs() throws NamingException {
System.setProperty("com.sun.jndi.ldap.connect.pool.debug", "fine");
System.setProperty("com.sun.jndi.ldap.connect.pool.maxsize", "1");
Hashtable<String,String> env = new Hashtable<String,String>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.SECURITY_PRINCIPAL, user);
env.put(Context.SECURITY_CREDENTIALS, passwd);
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.PROVIDER_URL, ldapUrl);
// use a connection pool
env.put("com.sun.jndi.ldap.connect.pool", "true"); // ----------------- (1)
// get a context from the pool.
DirContext context = new InitialDirContext(env); // -------------------- (2)
NamingEnumeration<SearchResult> results = context.search("", query, getSC());
// obviously the next two lines would normally be in a
// while(results.hasMore()) { ... = results.next(); } loop.
assertTrue(results.hasMore()); // this is only a problem when there are some results.
results.next(); // ----------------------------------------------------- (3)
// ensure the context is returned to the pool.
results.close();
context.close(); // ---------------------------------------------------- (4)
//System.gc(); // ------------------------------------------------------ (5)
new InitialDirContext(env); // hangs here! ---------------------------- (6)
}
With the code as it is, my console shows:
Create com.sun.jndi.ldap.LdapClient@1a7bf11[ldapad:389]
Use com.sun.jndi.ldap.LdapClient@1a7bf11
Whereas if I force the GC I additionally see:
Release com.sun.jndi.ldap.LdapClient@93dee9 <-- on GC
Use com.sun.jndi.ldap.LdapClient@93dee9 <-- on new InitialDirContext
After a bit of investigation I've found that the LDAP connection isn't returned to the pool because the SearchResult object contains a reference to the LdapCtx object.
If you replace
results.next();
With the following
SeachResult ob = results.next();
((Context)ob.getObject()).close();
The the connection will be correctly returned to the pool. This seems like a bug in the default implementation.
Theproblem doesn't exist when using the Spring LDAPTemplate because it provides a custom "java.naming.factory.object" in the environment that closes the LdapCtx as part of the process of constructing the SearchResult. This can be easily demostrated by adding the Spring LDAP library to your classpath and adding the following to the InitialContext
java.naming.factory.object=org.springframework.ldap.core.support.DefaultDirObjectFactory
When this is done the object held by the SearchResult changes from com.sun.jndi.ldap.LdapCtx:com.sun.jndi.ldap.LdapCtx to org.springframework.ldap.core.DirContextAdapter. The DefaultDirObjectFactory class is responsible for creating the DirContextAdapter and takes care to close the LdapCtx before returning the DirContextAdapter to the DirectoryManager. Here is the finally block from the DefaultDirObjectFactory
finally {
// It seems that the object supplied to the obj parameter is a
// DirContext instance with reference to the same Ldap connection as
// the original context. Since it is not the same instance (that's
// the nameCtx parameter) this one really needs to be closed in
// order to correctly clean up and return the connection to the pool
// when we're finished with the surrounding operation.
if (obj instanceof Context) {
Context ctx = (Context) obj;
try {
ctx.close();
}
catch (Exception e) {
// Never mind this
}
}
}