There are a few of them, examples below. Some work for us to track down it would seem.
SEVERE: The web application [/OLP] appears to have started a thread named [ActiveMQ Scheduler] but has failed to stop it. This is very likely to create a memory leak. SEVERE: The web application [/OLP] appears to have started a thread named [InactivityMonitor Async Task: java.util.concurrent.threadpoolexecutor$wor...@413fdef7[state = 0, empty queue]] but has failed to stop it. This is very likely to create a memory leak. SEVERE: The web application [/OLP] appears to have started a thread named [TcpSocketClose: java.util.concurrent.threadpoolexecutor$wor...@d91afbc[state = 0, empty queue]] but has failed to stop it. This is very likely to create a memory leak. SEVERE: The web application [/OLP] appears to have started a thread named [org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-1] but has failed to stop it. This is very likely to create a memory leak. SEVERE: The web application [/OLP] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@5fb5d830]) and a value of type org.springframework.security.core.context.SecurityContextImpl] (value [org.springframework.security.core.context.securitycontexti...@ffffffff: Null authentication]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. -----Original Message----- From: Pid [mailto:p...@pidster.com] Sent: Wednesday, 15 December 2010 12:00 p.m. To: Tomcat Users List Subject: Re: jndi-lookup fails, cured by tomcat restart On 14/12/2010 22:35, Dale Ogilvie wrote: > > We'll investigate the leak issue, there /are/ leaks from Spring active > mq code. Mind posting the leak warning from the logs? p > -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Wednesday, 15 December 2010 11:15 a.m. > To: Tomcat Users List > Subject: Re: jndi-lookup fails, cured by tomcat restart > > Dave, > > On 12/14/2010 4:56 PM, Dale Ogilvie wrote: >> Redeployment that first caused the issue was using manager web-app. >> We > >> tried other deployment options after that. > >> OS is RHEL5.x > >> Aha, scanning the logs around the first error I found the following >> in > >> catalina.2010-12-08.log. This message (and friends) is appearing >> prior > >> to the first failure to deploy our app. > >> Dec 8, 2010 7:09:33 PM >> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor >> processChildren >> SEVERE: Exception invoking periodic operation: >> java.lang.OutOfMemoryError: PermGen space > > If you start Tomcat fresh, deploy your webapp, then undeploy, do you > get any warnings about memory leaks? The manager webapp has a "Find Leaks" > button that you can click to see if Tomcat has detected any leaks. > > If there /are/ leaks, it means that multiple re-deployments will > ultimately lead to permgen exhaustion. > > -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
