Re: Memory Leaks ... (was: Re: JBoss and MyFaces ....)
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:
Re: JBoss and MyFaces ....
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
Memory Leaks ... (was: Re: JBoss and MyFaces ....)
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
Re: JBoss and MyFaces ....
Should be fixed in current snapshot ;) Regards, Jakob 2010/10/28 Matthias Wessendorf mat...@apache.org: 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 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Memory Leaks ... (was: Re: JBoss and MyFaces ....)
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
Re: JBoss and MyFaces ....
On Fri, Oct 15, 2010 at 2:47 AM, ssilv...@redhat.com wrote: Yes, the goal is to allow any version and any implementation of JSF. That's why you will see Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] What about MyFaces 1.2 ? :) Just to be clear, it's AS6 SNAPSHOT, not AS5. All Lincoln's fault! :)) The AS6 CR1 release will be out in a few weeks but you can get a nightly build if you want to try it now: https://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x/lastSuccessfulBuild/artifact/JBossAS_6_0/build/target/ Interesting timing, I think I will give it a shot, since I need to do some work/comparison on WebProfile Servers ;) I'd love to get feedback. See the short JSF on JBoss doc to see how to do things like assign a JSF impl to a particular WAR. Also, I don't think it's in the doc, but changing the default impl from Mojarra to MyFaces is just a matter of changing one value in an XML file. The doc is here: http://www.jboss.org/jbossas/docs/6-x/Component-Documentation/jsf.html Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Thanks for the integration work, Stan. Big thanks to Leo for driving this. -Matthias Stan Quoting Matthias Wessendorf mat...@apache.org: Matthias Wessendorf (@mwessendorf) has shared a Tweet with you: lincolnthree: MyFaces 2 is now included in JBoss AS 5 SNAPSHOT!! -Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] --http://www.twitter.com/lincolnthree/status/27372071638 sent from my Android phone -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: JBoss and MyFaces ....
Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. Werner
Re: JBoss and MyFaces ....
On Fri, Oct 15, 2010 at 10:15 AM, Werner Punz werner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: JBoss and MyFaces ....
Am 15.10.10 10:19, schrieb Matthias Wessendorf: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punzwerner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Btw. it is getting off topic, is it just me - but I have the impression that we get significantly less bugreports on the core in since 2.0.2 is out. Werner
Re: JBoss and MyFaces ....
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. Stan Quoting Matthias Wessendorf mat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punz werner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: JBoss and MyFaces ....
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
Re: JBoss and MyFaces ....
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
Re: JBoss and MyFaces ....
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? 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
Re: JBoss and MyFaces ....
The ThreadLocal should be cleared upon undeploy, but this does not cause the memory leak mentioned by Stan. You will get a PermGen error in about an hour. The PermGen Error comes when there is not enough heap space to load classes. I had this problem yesterday when doing a lot of tests with MyFaces webapptest. However, I don't really know how to fix this problem. Has anyone got an idea? Regards, Jakob 2010/10/15 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? 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 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: JBoss and MyFaces ....
The permgen error usually is an overload of classes which means if a class is loaded and loaded and loaded again. Maybe we have a problem in our way way instantiate classes dynamically so that they constantly are reregistered in the classloader and never dropped. Just a wild guess here. Werner Am 15.10.10 14:32, schrieb Jakob Korherr: The ThreadLocal should be cleared upon undeploy, but this does not cause the memory leak mentioned by Stan. You will get a PermGen error in about an hour. The PermGen Error comes when there is not enough heap space to load classes. I had this problem yesterday when doing a lot of tests with MyFaces webapptest. However, I don't really know how to fix this problem. Has anyone got an idea? Regards, Jakob 2010/10/15 Bruno Arandabrunoara...@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? 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 Punzwerner.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
Re: JBoss and MyFaces ....
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
Re: JBoss and MyFaces ....
Stan can you give us some info what the issue in Mojarra was? It might help us to track our problem down. My personal guess we that it might the our class instantiation code in shared, but I am guessing here as well. Werner 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. Stan Quoting Matthias Wessendorf mat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punz werner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: JBoss and MyFaces ....
Quoting Jakob Korherr jakob.korh...@gmail.com: The ThreadLocal should be cleared upon undeploy, but this does not cause the memory leak mentioned by Stan. I disagree. That could easily be the cause as was the case with Mojarra. You will get a PermGen error in about an hour. The PermGen Error comes when there is not enough heap space to load classes. I had this problem yesterday when doing a lot of tests with MyFaces webapptest. However, I don't really know how to fix this problem. Has anyone got an idea? Regards, Jakob 2010/10/15 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? 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 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: JBoss and MyFaces ....
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820 Quoting Werner Punz werner.p...@gmail.com: Stan can you give us some info what the issue in Mojarra was? It might help us to track our problem down. My personal guess we that it might the our class instantiation code in shared, but I am guessing here as well. Werner 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. Stan Quoting Matthias Wessendorf mat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punz werner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: JBoss and MyFaces ....
Thanks, Stan! We had a similar issue also in OpenWebBeans. The solution there was to clear() all ThreadLocals after usage, however not only in the ServletContextListener, but also in the RequestListener, because ThreadLocal.clear() only works for the current Thread. Thus we have to take a look at all our ThreadLocal instances in the code and check if they can be set at request time. If so, we may have to clear them at the end of every request. Regards, Jakob 2010/10/15 ssilv...@redhat.com: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820 Quoting Werner Punz werner.p...@gmail.com: Stan can you give us some info what the issue in Mojarra was? It might help us to track our problem down. My personal guess we that it might the our class instantiation code in shared, but I am guessing here as well. Werner 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. Stan Quoting Matthias Wessendorf mat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punz werner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- 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
Re: JBoss and MyFaces ....
You guys might want to check out the utility that Trinidad uses for registering ThreadLocals for clean up at the end of the request in org.apache.myfaces.trinidad.util.ThreadLocalUtils. -- Blake Sullivan On 10/15/10 5:52 AM, Jakob Korherr wrote: Thanks, Stan! We had a similar issue also in OpenWebBeans. The solution there was to clear() all ThreadLocals after usage, however not only in the ServletContextListener, but also in the RequestListener, because ThreadLocal.clear() only works for the current Thread. Thus we have to take a look at all our ThreadLocal instances in the code and check if they can be set at request time. If so, we may have to clear them at the end of every request. Regards, Jakob 2010/10/15ssilv...@redhat.com: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820 Quoting Werner Punzwerner.p...@gmail.com: Stan can you give us some info what the issue in Mojarra was? It might help us to track our problem down. My personal guess we that it might the our class instantiation code in shared, but I am guessing here as well. Werner 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. Stan Quoting Matthias Wessendorfmat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punzwerner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: JBoss and MyFaces ....
Hi Checking this issue, I think we should just get rid of that ThreadLocal var, because it is used as a hack to pass the right RuntimeConfig instance. Before JSF 2.0 this was required because there was not startup FacesContext, but now it exists, so it is valid to get the current ExternalContext and then the valid RuntimeConfig from application map. Maybe we should update jsf 1.2 branch to include the same concept. regards, Leonardo Uribe 2010/10/15 Blake Sullivan blake.sulli...@oracle.com You guys might want to check out the utility that Trinidad uses for registering ThreadLocals for clean up at the end of the request in org.apache.myfaces.trinidad.util.ThreadLocalUtils. -- Blake Sullivan On 10/15/10 5:52 AM, Jakob Korherr wrote: Thanks, Stan! We had a similar issue also in OpenWebBeans. The solution there was to clear() all ThreadLocals after usage, however not only in the ServletContextListener, but also in the RequestListener, because ThreadLocal.clear() only works for the current Thread. Thus we have to take a look at all our ThreadLocal instances in the code and check if they can be set at request time. If so, we may have to clear them at the end of every request. Regards, Jakob 2010/10/15ssilv...@redhat.com: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820 Quoting Werner Punzwerner.p...@gmail.com: Stan can you give us some info what the issue in Mojarra was? It might help us to track our problem down. My personal guess we that it might the our class instantiation code in shared, but I am guessing here as well. Werner 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. Stan Quoting Matthias Wessendorfmat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punzwerner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: JBoss and MyFaces ....
Thanks for the info, Blake! Leo, please take a look at my comment + patch on MYFACES-2942. I did exactly what you just said and I fully agree with you! If there are no objections to that patch, I'll commit it tomorrow! Regards, Jakob 2010/10/15 Leonardo Uribe lu4...@gmail.com: Hi Checking this issue, I think we should just get rid of that ThreadLocal var, because it is used as a hack to pass the right RuntimeConfig instance. Before JSF 2.0 this was required because there was not startup FacesContext, but now it exists, so it is valid to get the current ExternalContext and then the valid RuntimeConfig from application map. Maybe we should update jsf 1.2 branch to include the same concept. regards, Leonardo Uribe 2010/10/15 Blake Sullivan blake.sulli...@oracle.com You guys might want to check out the utility that Trinidad uses for registering ThreadLocals for clean up at the end of the request in org.apache.myfaces.trinidad.util.ThreadLocalUtils. -- Blake Sullivan On 10/15/10 5:52 AM, Jakob Korherr wrote: Thanks, Stan! We had a similar issue also in OpenWebBeans. The solution there was to clear() all ThreadLocals after usage, however not only in the ServletContextListener, but also in the RequestListener, because ThreadLocal.clear() only works for the current Thread. Thus we have to take a look at all our ThreadLocal instances in the code and check if they can be set at request time. If so, we may have to clear them at the end of every request. Regards, Jakob 2010/10/15ssilv...@redhat.com: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820 Quoting Werner Punzwerner.p...@gmail.com: Stan can you give us some info what the issue in Mojarra was? It might help us to track our problem down. My personal guess we that it might the our class instantiation code in shared, but I am guessing here as well. Werner 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. Stan Quoting Matthias Wessendorfmat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punzwerner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- 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
Re: JBoss and MyFaces ....
I completely agree that the best solution is to get rid of ThreadLocals that we don't need. -- Blake Sullivan On 10/15/10 11:26 AM, Leonardo Uribe wrote: Hi Checking this issue, I think we should just get rid of that ThreadLocal var, because it is used as a hack to pass the right RuntimeConfig instance. Before JSF 2.0 this was required because there was not startup FacesContext, but now it exists, so it is valid to get the current ExternalContext and then the valid RuntimeConfig from application map. Maybe we should update jsf 1.2 branch to include the same concept. regards, Leonardo Uribe 2010/10/15 Blake Sullivan blake.sulli...@oracle.com mailto:blake.sulli...@oracle.com You guys might want to check out the utility that Trinidad uses for registering ThreadLocals for clean up at the end of the request in org.apache.myfaces.trinidad.util.ThreadLocalUtils. -- Blake Sullivan On 10/15/10 5:52 AM, Jakob Korherr wrote: Thanks, Stan! We had a similar issue also in OpenWebBeans. The solution there was to clear() all ThreadLocals after usage, however not only in the ServletContextListener, but also in the RequestListener, because ThreadLocal.clear() only works for the current Thread. Thus we have to take a look at all our ThreadLocal instances in the code and check if they can be set at request time. If so, we may have to clear them at the end of every request. Regards, Jakob 2010/10/15ssilv...@redhat.com mailto:ssilv...@redhat.com: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820 Quoting Werner Punzwerner.p...@gmail.com mailto:werner.p...@gmail.com: Stan can you give us some info what the issue in Mojarra was? It might help us to track our problem down. My personal guess we that it might the our class instantiation code in shared, but I am guessing here as well. Werner Am 15.10.10 14:04, schrieb ssilv...@redhat.com mailto: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. Stan Quoting Matthias Wessendorfmat...@apache.org mailto:mat...@apache.org: On Fri, Oct 15, 2010 at 10:15 AM, Werner Punzwerner.p...@gmail.com mailto:werner.p...@gmail.com wrote: Am 15.10.10 09:26, schrieb Matthias Wessendorf: Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. +1 you really want 2.0.2 ;) Hehe I guess Myfaces 2.0.2 performance also will be better due to the performance work which went in between 2.0.1 and 2.0.2. that's why ;) Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: JBoss and MyFaces ....
Am 14.10.10 22:32, schrieb Matthias Wessendorf: Matthias Wessendorf (@mwessendorf) has shared a Tweet with you: lincolnthree: MyFaces 2 is now included in JBoss AS 5 SNAPSHOT!! -Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] --http://www.twitter.com/lincolnthree/status/27372071638 sent from my Android phone Oha... this is big news... Werner
Re: JBoss and MyFaces ....
Congrats to everyone involved - you did great work to make this happen! all the best, Martin On 10/14/10, Werner Punz werner.p...@gmail.com wrote: Am 14.10.10 22:32, schrieb Matthias Wessendorf: Matthias Wessendorf (@mwessendorf) has shared a Tweet with you: lincolnthree: MyFaces 2 is now included in JBoss AS 5 SNAPSHOT!! -Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] --http://www.twitter.com/lincolnthree/status/27372071638 sent from my Android phone Oha... this is big news... Werner -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: JBoss and MyFaces ....
Yes, the goal is to allow any version and any implementation of JSF. That's why you will see Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] Just to be clear, it's AS6 SNAPSHOT, not AS5. The AS6 CR1 release will be out in a few weeks but you can get a nightly build if you want to try it now: https://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x/lastSuccessfulBuild/artifact/JBossAS_6_0/build/target/ I'd love to get feedback. See the short JSF on JBoss doc to see how to do things like assign a JSF impl to a particular WAR. Also, I don't think it's in the doc, but changing the default impl from Mojarra to MyFaces is just a matter of changing one value in an XML file. The doc is here: http://www.jboss.org/jbossas/docs/6-x/Component-Documentation/jsf.html Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. Stan Quoting Matthias Wessendorf mat...@apache.org: Matthias Wessendorf (@mwessendorf) has shared a Tweet with you: lincolnthree: MyFaces 2 is now included in JBoss AS 5 SNAPSHOT!! -Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] --http://www.twitter.com/lincolnthree/status/27372071638 sent from my Android phone
Re: JBoss and MyFaces ....
Hi 2010/10/14 ssilv...@redhat.com Yes, the goal is to allow any version and any implementation of JSF. That's why you will see Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] Just to be clear, it's AS6 SNAPSHOT, not AS5. The AS6 CR1 release will be out in a few weeks but you can get a nightly build if you want to try it now: https://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x/lastSuccessfulBuild/artifact/JBossAS_6_0/build/target/ I'd love to get feedback. See the short JSF on JBoss doc to see how to do things like assign a JSF impl to a particular WAR. Also, I don't think it's in the doc, but changing the default impl from Mojarra to MyFaces is just a matter of changing one value in an XML file. The doc is here: http://www.jboss.org/jbossas/docs/6-x/Component-Documentation/jsf.html Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. Great! It makes me happy :-). I'll keep an eye on this one. As soon as we have feedback about if the integration points are ok, I can make another release. Leonardo Uribe
