Hi André, Thanks a lot for your response and the relevant information.
Indeed, we have noticed the similar behavior when hot reloading a web-app with solr after changing some of the classes. The only bad consequence of this that luckily does not happen too often, is that the web app becomes stale. So we prefer actually (re)deploying via tomcat restart. Thanks, Dmitry On Thu, Apr 11, 2013 at 6:01 PM, Andre Bois-Crettez <andre.b...@kelkoo.com>wrote: > On 04/11/2013 08:49 AM, Dmitry Kan wrote: > >> SEVERE: The web application [/solr] appears to have started a thread named >> [**MultiThreadedHttpConnectionMan**ager cleanup] but has failed to stop >> it. >> This is very likely to create a memory leak. >> Apr 11, 2013 6:38:14 AM org.apache.catalina.loader.**WebappClassLoader >> clearThreadLocalMap >> > > To my understanding this kind of leak only is a problem if the Java code > is *reloaded* while the tomcat JVM is not stopped. > For example when reloadable="true" in the Context of the web application > and you change files in WEB-INF or .war : what would happen is that each > existing threadlocals would continue to live (potentially holding > references to other stuff and preventing GC) while new threadlocals are > created. > > http://wiki.apache.org/tomcat/**MemoryLeakProtection<http://wiki.apache.org/tomcat/MemoryLeakProtection> > > If you stop tomcat entirely each time, you should be safe. > > > -- > André Bois-Crettez > > Search technology, Kelkoo > http://www.kelkoo.com/ > > > Kelkoo SAS > Société par Actions Simplifiée > Au capital de € 4.168.964,30 > Siège social : 8, rue du Sentier 75002 Paris > 425 093 069 RCS Paris > > Ce message et les pièces jointes sont confidentiels et établis à > l'attention exclusive de leurs destinataires. Si vous n'êtes pas le > destinataire de ce message, merci de le détruire et d'en avertir > l'expéditeur. >
