>>> ok, i revoke my "nevermind" message, even after I removed >>> JreMemoryLeakPreventionListener >>> I still get the warning. Even weirder: >>> >>> Oct 28, 2010 3:50:55 PM org.apache.catalina.core.StandardService stop >>> INFO: Stopping service Catalina >>> Oct 28, 2010 3:50:55 PM org.apache.catalina.loader.WebappClassLoader >>> clearReferencesThreads >>> SEVERE: The web application [/moskitodemo] appears to have started a >>> thread named [Poller SunPKCS11-Darwin] but has failed to stop it. This >>> is very likely to create a memory leak. >>> >> >> Note the word 'likely' is not 'defiantly', it is possible that your >> implementation is 'not' creating a memory leak. >> > > but a SEVERE log message should be pretty sure and not likely.
I agree a WARNING or INFO is more correct on shutdown. This would only be SEVERE if you were restarting your container with a manager or dropping in a new WAR and the JVM will continue running. Maybe the Memory Leak detection ought to have some parameter about whether the Sys Admin actually cares? Or, better couldn't it know if the whole JVM is going down and adjust the level and message accordingly? My 2 cents. Regards, Dave > >> If tomcat launches an independent thread (not a tomcat thread) that refers >> to objects within the tomcat instance (and its pool of threads), this is >> when a memory leak would occur. >> >> This is because objects referenced by the independent thread 'and' the >> tomcat instance would not be GC'ed when tomcat shuts down, because they are >> still referenced by a living thread. > > I really don't get it. I'm stopping tomcat. What do I care about > objects living in a webapp which is DEAD in a second in a VM which > will be dead in another second? > >> >> 'Generally' you will want to stop the independent threads when tomcat shuts >> down, thus removing the 'likelihood' of memory leaks. > > No actually I don't care. If they have jobs to do, they are free to > define their shutdown hooks. Otherwise all daemon threads are > automatically killed if the vm is killed. > >> >> If the independent threads have their own shut down hooks that realise >> tomcat is shutting down and dereference any appropriate objects, a memory >> leak will 'not' occur. >> >> If you want your independent threads to shut down with tomcat because they >> do not have the own mechanisms, implement a >> ServletContextListener.contextDestroyed that does so. > > Yeah, but I actually don't. I mean I'm hitting ctrl-c in a terminal > with running bin/catalina.sh run. > I just want to get rid of the message to prevent the admins from > jumping up and down cause they detect a SEVERE message in the logs... > regards > Leon > > >> >> Regards, >> >> Simon >> >>> Oct 28, 2010 3:50:55 PM org.apache.catalina.loader.WebappClassLoader >>> clearReferencesThreads >>> SEVERE: The web application [/moskitodemo] appears to have started a >>> thread named [MoskitoIntervalUpdater] but has failed to stop it. This >>> is very likely to create a memory leak. >>> Oct 28, 2010 3:50:55 PM org.apache.catalina.loader.WebappClassLoader >>> clearReferencesThreads >>> SEVERE: The web application [/moskitodemo] appears to have started a >>> thread named [MoskitoMemoryReader] but has failed to stop it. This is >>> very likely to create a memory leak. >>> Oct 28, 2010 3:50:55 PM org.apache.catalina.loader.WebappClassLoader >>> clearReferencesThreads >>> SEVERE: The web application [/moskitodemo] appears to have started a >>> thread named [MoskitoMemoryPoolReader] but has failed to stop it. This >>> is very likely to create a memory leak. >>> Oct 28, 2010 3:50:55 PM org.apache.catalina.loader.WebappClassLoader >>> clearReferencesThreads >>> SEVERE: The web application [/moskitodemo] appears to have started a >>> thread named [MoskitoMemoryPoolReader] but has failed to stop it. This >>> is very likely to create a memory leak. >>> Oct 28, 2010 3:50:55 PM org.apache.catalina.loader.WebappClassLoader >>> clearReferencesThreads >>> SEVERE: The web application [/moskitodemo] appears to have started a >>> thread named [Thread-6] but has failed to stop it. This is very likely >>> to create a memory leak. >>> Oct 28, 2010 3:50:56 PM org.apache.coyote.http11.Http11Protocol destroy >>> INFO: Stopping Coyote HTTP/1.1 on http-8080 >>> >>> anyplace else except the server.xml to fix it? >>> >>> regards >>> Leon >>> >>> On Thu, Oct 28, 2010 at 3:46 PM, Leon Rosenberg >>> <rosenberg.l...@gmail.com> wrote: >>> >>>> >>>> nevermind, found it, sorry for disturbing. >>>> >>>> On Thu, Oct 28, 2010 at 3:44 PM, Leon Rosenberg >>>> <rosenberg.l...@gmail.com> wrote: >>>> >>>>> >>>>> Hello, >>>>> >>>>> I investigated an issue (another thread) with new error messages after >>>>> tomcat update: >>>>> >>>>> SEVERE: The web application [/moskitodemo] appears to have started a >>>>> thread named [MoskitoMemoryPoolReader] but has failed to stop it. This >>>>> is very likely to create a memory leak. >>>>> >>>>> >>>>> After some research and discussions with colleagues we came to the >>>>> conclusion that this message is ... well not helping us. Is there a >>>>> possibility to turn it off? Its annoying to have such messages in the >>>>> logs >>>>> after a server shutdown. For explanation: I'm not planing to use >>>>> webapp reload in my environment, hence, this message is actually just >>>>> spam. >>>>> >>>>> regards >>>>> Leon >>>>> >>>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
