[prev in list] [next in list] [prev in thread] [next in thread] 

List:       myfaces-dev
Subject:    Re: Memory Leaks ... (was: Re: JBoss and MyFaces ....)
From:       Mike Kienenberger <mkienenb () gmail ! com>
Date:       2010-10-28 20:08:37
Message-ID: AANLkTimuO8mMfns29VQM_xKYCSHvNP3=aP=KkgbJPyOF () mail ! gmail ! com
[Download RAW message or body]

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 <matzew@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 <matzew@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.ThreadLocal@203822fc]) and a value of type
>> [org.apache.myfaces.context.servlet.StartupFacesContextImpl] (value
>> [org.apache.myfaces.context.servlet.StartupFacesContextImpl@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.ThreadLocal@faaf84c]) and a value of type
>> [org.apache.myfaces.context.servlet.StartupFacesContextImpl] (value
>> [org.apache.myfaces.context.servlet.StartupFacesContextImpl@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.ThreadLocal@4dcc8fa3]) and a value of type
>> [org.apache.myfaces.config.RuntimeConfig] (value
>> [org.apache.myfaces.config.RuntimeConfig@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,  <ssilvert@redhat.com> wrote:
>>> Quoting Bruno Aranda <brunoaranda@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.ThreadLocal@41649a55]) and a value of type
>>>> [org.apache.myfaces.config.RuntimeConfig] (value
>>>> [org.apache.myfaces.config.RuntimeConfig@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, <ssilvert@redhat.com> wrote:
>>>>
>>>>> Thanks Werner.  Hope someone can take a look before 2.0.3.
>>>>>
>>>>> Stan
>>>>>
>>>>>
>>>>> Quoting Werner Punz <werner.punz@gmail.com>:
>>>>>
>>>>>  Am 15.10.10 14:04, schrieb ssilvert@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
>

[prev in list] [next in list] [prev in thread] [next in thread]