directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: Question about GroovyLDAP
Date Mon, 19 Dec 2011 22:03:10 GMT
Always close the namingEnumeration otherwise you will exhaust the
connection pool. This a JNDI trap, a nasty one...
Le 19 déc. 2011 23:00, "Maciej Macowicz" <maciej.macowicz@gmail.com> a
écrit :

> Sorry for the noice, the similar problem occurs in Java, connections are
> stuck ...
> Would you have any idea? Maybe this is due to the Mac OS X, I'll check on
> Linux tomorrow.
>
> Cheers - Maciek
>
> On Mon, Dec 19, 2011 at 5:07 PM, Maciej Macowicz <maciej.macowicz@epfl.ch>wrote:
>
>> Hello,
>>
>> 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,
>> "org.apache.directory.groovyldap.jndi.DirContextToMapObjectFactory" );
>>        env.put("com.sun.jndi.ldap.connect.pool", "true");
>>
>>        return env;
>>    }
>>
>>    @Test void testConnect() {
>>        System.setProperty("com.sun.jndi.ldap.connect.pool.debug","all");
>>        System.setProperty("com.sun.jndi.ldap.connect.pool.maxsize","2");
>>        LdapContext ctx= null
>>        (1..10).each {
>>            println " *** Creating connection #$it ***"
>>            try {
>>                ctx= new InitialLdapContext(createEnvironment(), null)
>>                sleep(1)
>>            } catch (NamingException ne) {
>>                println " Something went wrong ... $ne"
>>            } finally {
>>                ctx.close()
>>                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 = ctx.search( "...",
>> "(&(objectclass=person)(cn=Mac*))", null, ctls );
>>            while ( enm.hasMore() ) {
>>                SearchResult sr = enm.next();
>>                Object obj = sr.getObject();
>>                // closure.call( 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 -
>>
>>
>> --
>> Maciek
>> ______________________________oOo_______________________________
>> Dr. Maciej Macowicz --> http://personnes.epfl.ch/maciej.macowicz
>>                          KIS - Knowledge & Information Services
>>           Ecole Polytechnique Federale de Lausanne, Switzerland
>>
>>
>

Mime
View raw message