Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 396FA784F for ; Mon, 19 Dec 2011 22:03:13 +0000 (UTC) Received: (qmail 90819 invoked by uid 500); 19 Dec 2011 22:03:13 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 90780 invoked by uid 500); 19 Dec 2011 22:03:12 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 90772 invoked by uid 99); 19 Dec 2011 22:03:12 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Dec 2011 22:03:12 +0000 Received: from localhost (HELO mail-wi0-f178.google.com) (127.0.0.1) (smtp-auth username elecharny, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Dec 2011 22:03:12 +0000 Received: by wibhi5 with SMTP id hi5so1426096wib.37 for ; Mon, 19 Dec 2011 14:03:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.90.40 with SMTP id bt8mr2466867wib.4.1324332190926; Mon, 19 Dec 2011 14:03:10 -0800 (PST) Reply-To: elecharny@apache.org Received: by 10.180.84.130 with HTTP; Mon, 19 Dec 2011 14:03:10 -0800 (PST) Received: by 10.180.84.130 with HTTP; Mon, 19 Dec 2011 14:03:10 -0800 (PST) In-Reply-To: References: Date: Mon, 19 Dec 2011 23:03:10 +0100 Message-ID: Subject: Re: Question about GroovyLDAP From: Emmanuel Lecharny To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=f46d043be05ece054704b4791dac --f46d043be05ece054704b4791dac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Always close the namingEnumeration otherwise you will exhaust the connection pool. This a JNDI trap, a nasty one... Le 19 d=E9c. 2011 23:00, "Maciej Macowicz" a =E9crit : > 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 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 =3D 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=3D null >> (1..10).each { >> println " *** Creating connection #$it ***" >> try { >> ctx=3D 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 =3D new SearchControls(); >> ctls.setSearchScope( SearchControls.SUBTREE_SCOPE ); >> ctls.setReturningObjFlag( true ) >> >> NamingEnumeration enm =3D ctx.search( "...", >> "(&(objectclass=3Dperson)(cn=3DMac*))", null, ctls ); >> while ( enm.hasMore() ) { >> SearchResult sr =3D enm.next(); >> Object obj =3D 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 ha= s >> 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 >> >> > --f46d043be05ece054704b4791dac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Always close the namingEnumeration otherwise you will exhaust the connec= tion pool. This a JNDI trap, a nasty one...

Le 19 d=E9c. 2011 23:00, "Maciej Macowicz&q= uot; <maciej.macowicz@gmail= .com> a =E9crit=A0:
Sorry for the noice, the similar problem occurs in Java, connections are st= uck ...=A0
Would you have any idea? Maybe this is due to the Mac OS X, = I'll check on Linux tomorrow.

Cheers - Maciek<= br>
On Mon, Dec 19, 2011 at 5:07 PM, Maciej Maco= wicz <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 stu= ck 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 :

=A0 =A0def createEnvironment() {
=A0 =A0 =A0 =A0Hashtable env =3D new Hashtable(11);
=A0 =A0 =A0 =A0env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi= .ldap.LdapCtxFactory");
=A0 =A0 =A0 =A0env.put(Context.PROVIDER_URL, "ldap://.../");
=A0 =A0 =A0 =A0env.put(Context.OBJECT_FACTORIES, "org.apache.director= y.groovyldap.jndi.DirContextToMapObjectFactory" );
=A0 =A0 =A0 =A0env.put("com.sun.jndi.ldap.connect.pool", "t= rue");

=A0 =A0 =A0 =A0return env;
=A0 =A0}

=A0 =A0@Test void testConnect() {
=A0 =A0 =A0 =A0System.setProperty("com.sun.jndi.ldap.connect.pool.deb= ug","all");
=A0 =A0 =A0 =A0System.setProperty("com.sun.jndi.ldap.connect.pool.max= size","2");
=A0 =A0 =A0 =A0LdapContext ctx=3D null
=A0 =A0 =A0 =A0(1..10).each {
=A0 =A0 =A0 =A0 =A0 =A0println " *** Creating connection #$it ***&quo= t;
=A0 =A0 =A0 =A0 =A0 =A0try {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ctx=3D new InitialLdapContext(createEnviron= ment(), null)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sleep(1)
=A0 =A0 =A0 =A0 =A0 =A0} catch (NamingException ne) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0println " Something went wrong ... $ne= "
=A0 =A0 =A0 =A0 =A0 =A0} finally {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ctx.close()
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0println " *** Closed connection #$it *= **"
=A0 =A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0}
=A0 =A0}

But when replacing "sleep(1)" in testConnect() by something more = concrete, e.g.
=A0 =A0 =A0 =A0 =A0 =A0SearchControls ctls =3D new SearchControls();
=A0 =A0 =A0 =A0 =A0 =A0ctls.setSearchScope( SearchControls.SUBTREE_SCOPE )= ;
=A0 =A0 =A0 =A0 =A0 =A0ctls.setReturningObjFlag( true )

=A0 =A0 =A0 =A0 =A0 =A0NamingEnumeration<SearchResult> enm =3D ctx.s= earch( "...", "(&(objectclass=3Dperson)(cn=3DMac*))"= ;, null, ctls );
=A0 =A0 =A0 =A0 =A0 =A0while ( enm.hasMore() ) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0SearchResult sr =3D enm.next();
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Object obj =3D sr.getObject();
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// closure.call( obj );
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0println " *** Found: ${obj.dn}" =A0 =A0 =A0 =A0 =A0 =A0}

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

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

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
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0KIS - Knowledge & I= nformation Services
=A0 =A0 =A0 =A0 =A0 Ecole Polytechnique Federale de Lausanne, Switzerland<= br>

--f46d043be05ece054704b4791dac--