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 AA787779A for ; Mon, 19 Dec 2011 22:00:21 +0000 (UTC) Received: (qmail 87508 invoked by uid 500); 19 Dec 2011 22:00:21 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 87452 invoked by uid 500); 19 Dec 2011 22:00:21 -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 Delivered-To: moderator for dev@directory.apache.org Received: (qmail 94104 invoked by uid 99); 19 Dec 2011 16:40:53 -0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of maciej.macowicz@gmail.com designates 74.125.82.44 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Z+rPvC0d2GhY0jyF+oWFRqTo0jjcBJbieSVNH2/c0fk=; b=bwiWtCi8dUW/kQNZSG0N72Qfkst88i3OcSwYxApYzzXi0q5ZnWRwg9VyWVgGrWcu3+ aoS2leWAzj3zwGsazJcQz4SPlOL8I1NGJ0DAybWmLY9fOyotML2LidXG0iFq9cDoLXT+ AdeXZxZ1R8KNkbZTDqA+8WT62BVO6DkPIoRgo= MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 19 Dec 2011 17:40:26 +0100 Message-ID: Subject: Re: Question about GroovyLDAP From: Maciej Macowicz To: dev@directory.apache.org Content-Type: multipart/alternative; boundary=0015174c0f64954c7904b4749b0d --0015174c0f64954c7904b4749b0d Content-Type: text/plain; charset=ISO-8859-1 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 = 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 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 > > --0015174c0f64954c7904b4749b0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 <macie= j.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>

--0015174c0f64954c7904b4749b0d--