myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: JBoss and MyFaces ....
Date Fri, 15 Oct 2010 18:26:57 GMT
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.sullivan@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<ssilvert@redhat.com>:
>>
>>> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820
>>>
>>> Quoting Werner Punz<werner.punz@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 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.
>>>>>
>>>>> Stan
>>>>>
>>>>> Quoting Matthias Wessendorf<matzew@apache.org>:
>>>>>
>>>>>  On Fri, Oct 15, 2010 at 10:15 AM, Werner Punz<werner.punz@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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>

Mime
View raw message