directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maciej Macowicz <>
Subject Question about GroovyLDAP
Date Mon, 19 Dec 2011 16:07:00 GMT

I really appreciated your library, even if this is not yet officialized as Apache project.
However, when trying to integrate it, I found a strange problem when trying to use pooled
LDAP connections.
More precisely, under some circumstances the connection seems to remain stuck and is NOT returned
the pool, 
despite of ctx.close() previously called.

Here are the code running without problems, the pool size is always 1 : 

    def createEnvironment() {
        Hashtable env = new Hashtable(11);
        env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
        env.put(Context.PROVIDER_URL, "ldap://.../");
        env.put(Context.OBJECT_FACTORIES, ""
        env.put("com.sun.jndi.ldap.connect.pool", "true");

        return env;

    @Test void testConnect() {
        LdapContext ctx= null
        (1..10).each {
            println " *** Creating connection #$it ***"
            try {
                ctx= new InitialLdapContext(createEnvironment(), null)
            } catch (NamingException ne) {
                println " Something went wrong ... $ne"
            } finally {
                println " *** Closed connection #$it ***"
But when replacing "sleep(1)" in testConnect() by something more concrete, e.g. 
            SearchControls ctls = new SearchControls();
            ctls.setSearchScope( SearchControls.SUBTREE_SCOPE );
            ctls.setReturningObjFlag( true )

            NamingEnumeration<SearchResult> enm = "...", "(&(objectclass=person)(cn=Mac*))",
null, ctls );
            while ( enm.hasMore() ) {
                SearchResult sr =;
                Object obj = sr.getObject();
                // obj );
                println " *** Found: ${obj.dn}"

... connections become stuck, they are NOT returned to the pool and the pool simply goes full
It seems ctx.close() has no effect... 

I suspect the dispatch of the method ctx.close() after the ctx object has been modified, or
something like that, 
but frankly I have been running out of ideas, may be this is a Groovy problem? 

Would you have any idea? 

Thank you very much, looking forward to hearing from you - 

Cheers -

Dr. Maciej Macowicz -->
                          KIS - Knowledge & Information Services
           Ecole Polytechnique Federale de Lausanne, Switzerland

View raw message