Hi guys, Thanks for the links! Actually I used both of them while working on the memory leak problem.
The tomcat wiki entry is a great resource and the Eclipse Memory Analyzer is a neat tool (if you know how to use it, for which you need some tutorials at first). Regards, Jakob 2010/10/28 Mike Kienenberger <mkien...@gmail.com>: > I started reading the link you posted and ended up here: > > This also talks about classloader memory leaks in general, how to > identify them using the Eclipse Memory Analyzer (can also be run as a > standalone app), and how to determine what needs to be done to fix > them. > > http://dev.eclipse.org/blogs/memoryanalyzer/2008/05/17/the-unknown-generation-perm/ > > > > On Thu, Oct 28, 2010 at 4:35 AM, Matthias Wessendorf <mat...@apache.org> > wrote: >> Oh, the tomcat folks have a good write on this topic: >> http://wiki.apache.org/tomcat/MemoryLeakProtection >> >> On Thu, Oct 28, 2010 at 10:33 AM, Matthias Wessendorf <mat...@apache.org> >> wrote: >>> In Tomcat I also see this, using 2.0.2: >>> >>> points to "StartupFacesContextImpl" and to "RuntimeConfig" as well >>> >>> .10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader >>> clearThreadLocalMap >>> SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal >>> with key of type [java.lang.ThreadLocal] (value >>> [java.lang.threadlo...@203822fc]) and a value of type >>> [org.apache.myfaces.context.servlet.StartupFacesContextImpl] (value >>> [org.apache.myfaces.context.servlet.startupfacescontexti...@4580deea]) >>> but failed to remove it when the web application was stopped. This is >>> very likely to create a memory leak. >>> 27.10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader >>> clearThreadLocalMap >>> SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal >>> with key of type [java.lang.ThreadLocal] (value >>> [java.lang.threadlo...@faaf84c]) and a value of type >>> [org.apache.myfaces.context.servlet.StartupFacesContextImpl] (value >>> [org.apache.myfaces.context.servlet.startupfacescontexti...@21934d9d]) >>> but failed to remove it when the web application was stopped. This is >>> very likely to create a memory leak. >>> 27.10.2010 15:37:54 org.apache.catalina.loader.WebappClassLoader >>> clearThreadLocalMap >>> SCHWERWIEGEND: The web application [/webprofile] created a ThreadLocal >>> with key of type [java.lang.ThreadLocal] (value >>> [java.lang.threadlo...@4dcc8fa3]) and a value of type >>> [org.apache.myfaces.config.RuntimeConfig] (value >>> [org.apache.myfaces.config.runtimecon...@30ea3e3c]) but failed to >>> remove it when the web application was stopped. This is very likely to >>> create a memory leak. >>> >>> >>> >>> >>> .Matthias >>> >>> On Fri, Oct 15, 2010 at 2:36 PM, <ssilv...@redhat.com> wrote: >>>> Quoting Bruno Aranda <brunoara...@gmail.com>: >>>> >>>>> Using tomcat 7 I get this warning... >>>>> >>>>> SEVERE: The web application [/editor-2.0-SNAPSHOT] created a ThreadLocal >>>>> with key of type [java.lang.ThreadLocal] (value >>>>> [java.lang.threadlo...@41649a55]) and a value of type >>>>> [org.apache.myfaces.config.RuntimeConfig] (value >>>>> [org.apache.myfaces.config.runtimecon...@33d063fd]) but failed to remove >>>>> it >>>>> when the web application was stopped. This is very likely to create a >>>>> memory >>>>> leak. >>>>> >>>>> I don't know if the RuntimeConfig could be the one responsible of the leak >>>>> in Jboss? >>>> >>>> That's exactly the kind of leak that Mojarra had. >>>> >>>> The other leak I've been seeing in code lately is where you use a >>>> WeakHashMap and the value contains the key. Your key/value will never be >>>> removed in that case. See the WeakHashMap javadoc if you aren't familiar >>>> with that leak. >>>> >>>>> >>>>> Bruno >>>>> >>>>> On 15 October 2010 13:12, <ssilv...@redhat.com> wrote: >>>>> >>>>>> Thanks Werner. Hope someone can take a look before 2.0.3. >>>>>> >>>>>> Stan >>>>>> >>>>>> >>>>>> Quoting Werner Punz <werner.p...@gmail.com>: >>>>>> >>>>>> Am 15.10.10 14:04, schrieb ssilv...@redhat.com: >>>>>>> >>>>>>>> I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an >>>>>>>> undeploy leak and it took a long time to track it down. The same test >>>>>>>> I >>>>>>>> was using on Mojarra also failed on MyFaces but I haven't had time to >>>>>>>> track down the leak in MyFaces. >>>>>>>> >>>>>>>> Maybe this is fixed in 2.0.2? If not maybe someone can go ahead and >>>>>>>> take a look? The mem leak keeps MyFaces from passing TCK on JBoss AS. >>>>>>>> To test, all you need to do is create a small exploaded JSF app. Then >>>>>>>> have a script that touches web.xml every 10 seconds. That will cause >>>>>>>> the app to redeploy. You will get a PermGen error in about an hour. >>>>>>>> >>>>>>> >>>>>>> Hi Stan I opened a ticket under >>>>>>> https://issues.apache.org/jira/browse/MYFACES-2942 >>>>>>> >>>>>>> Just to make sure the info is not lost. >>>>>>> I hope you dont mind that I just copy pasted the info you gave here. >>>>>>> >>>>>>> >>>>>>> Werner >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
