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
