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













Reply via email to