This one has me curious... You may just be able to clean up the references to the LdapContext.
From: http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/config.html By default, idle connections remain in the pool indefinitely until they are garbage-collected. On Wed, Jan 22, 2014 at 10:25 AM, Stuart Broad <[email protected]> wrote: > Hi Brian, > > Thanks for the suggestion. I had not thought of implementing > 'Destroyable' on the LDAP realm (I noticed that the JndiLdapRealm I > subclass does not implement it). However if I did implement it I am not > sure what to do within that method. > > After each use of an LDAP context in the finally I call the following > method: > > public static void closeContext(LdapContext ctx) { > try { > if (ctx != null) { > ctx.close(); > } > } catch (NamingException e) { > log.error("Exception while closing LDAP context. ", e); > } > } > > The LdapContextFactory (held on to by JndiLdapRealm does not have any > destroy/close type methods exposed). > > Cheers, > > Stuart > > > On Wed, Jan 22, 2014 at 3:12 PM, Brian Demers <[email protected]>wrote: > >> You could try cleaning up the LDAP Context my implementing 'Destroyable' >> in the LDAP realm (if it isn't already getting cleaned up somewhere) >> >> >> On Wed, Jan 22, 2014 at 9:49 AM, Stuart Broad <[email protected]>wrote: >> >>> Update: >>> >>> I have noticed that the SEVERE log message does not occur when using >>> ldaps (rather than ldap) for the url. >>> >>> I tried turning off pooling (?) but this did not work for me: >>> >>> JAVA_OPTS="$JAVA_OPTS -Dcom.sun.jndi.ldap.connect.pool=false" >>> >>> >>> >>> On Thu, Jan 16, 2014 at 4:47 PM, Stuart Broad <[email protected]>wrote: >>> >>>> Hi, >>>> >>>> After logging in to my web app for the first time using an >>>> JndiLdapRealm a connection thread is created. Although I have not >>>> explicitly configured connection pooling I believe this is default java >>>> ldap behaviour. >>>> >>>> When I shut tomcat down I get the following SEVERE log message: >>>> >>>> SEVERE: The web application [/xyz] appears to have started a thread >>>> named [Thread-56] but has failed to stop it. This is very likely to create >>>> a memory leak. >>>> >>>> I took a thread dump and found that the thread in question is this: >>>> >>>> "Thread-56" daemon prio=5 tid=7f855906f800 nid=0x11082f000 runnable >>>> [11082e000] >>>> >>>> java.lang.Thread.State: RUNNABLE >>>> >>>> at java.net.SocketInputStream.socketRead0(Native Method) >>>> >>>> at java.net.SocketInputStream.read(SocketInputStream.java:129) >>>> >>>> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) >>>> >>>> at java.io.BufferedInputStream.read1(BufferedInputStream.java:258) >>>> >>>> at java.io.BufferedInputStream.read(BufferedInputStream.java:317) >>>> >>>> - locked <7dffa0d08> (a java.io.BufferedInputStream) >>>> >>>> at com.sun.jndi.ldap.Connection.run(Connection.java:836) >>>> >>>> at java.lang.Thread.run(Thread.java:680) >>>> >>>> >>>> I am destroying my SecurityManager at shutdown. Is there an easy way >>>> to cleanup these LDAP connection threads? I saw mention of simply turning >>>> off connection pooling but I don't think that is ideal. >>>> >>>> >>>> Cheers, >>>> >>>> >>>> Stuart >>>> >>> >>> >> >
