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/15<ssilv...@redhat.com <mailto:ssilv...@redhat.com>>:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820
Quoting Werner Punz<werner.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 Wessendorf<mat...@apache.org
<mailto:mat...@apache.org>>:
On Fri, Oct 15, 2010 at 10:15 AM, Werner
Punz<werner.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
