portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Müller <joac...@wemove.com>
Subject Re: JetspeedEngine bound to threadlocal?
Date Tue, 27 Nov 2007 09:25:48 GMT
Hi Ate.

Fine to me as well so far. We still need to clarify what caused the high
number of references on the production system. I may return on this ;-).

Regards,
Joachim


Ate Douma schrieb:
> Hi Joachim,
> 
> Seeing this explained now, do you agree this turned out to be no problem
> after all?
> As after each request the threadlocal in Pluto is properly cleared it
> seems fine by me.
> 
> Regards,
> 
> Ate
> 
> Joachim Müller wrote:
>> Hi Ate, Frank.
>>
>> I found it. The treadlocal is used in pluto 1.0.1:
>>
>> The JetspeedEngine is stored in a threadlocal in
>>
>> [Pluto]PortletContainerServices.prepare()
>>
>> and released here:
>>
>> [Pluto]PortletContainerServices.release()
>>
>> Both methods are called from
>>
>> [Pluto]PortletContainerImpl.renderPortlet()
>>
>> which is called from
>>
>> [Jetspeed]JetspeedPortletContainerWrapper.renderPortlet().
>>
>> PortletContainerImpl is initialized with the JetspeedEngine via spring
>> in jetspeed-spring.xml.
>>
>> Since [Pluto]PortletContainerServices.release() is called in a finally
>> block all threadlocals should be cleaned up. If they do not and
>> references do pile up under load condition it could be a sign that the
>> portlets rendered in [Pluto]PortletContainerImpl.renderPortlet() are
>> taking too long render.
>>
>> The effect is request driven. If jetspeed idles no threadlocal
>> references to JetspeedEngine can be seen anymore at least in my tests
>> with the standard jetspeed 2.1.2 distribution.
>>
>>
>> Regards,
>> Joachim
>>
>>
>> Joachim Müller schrieb:
>>>> Wow, that's quite a lot indeed.
>>>> I don't have a quick answer right now but I'll see if I can trace this
>>>> down somehow next week and then come back to you.
>>> Would be great, because I am clueless at the moment. The existence of
>>> the stack inside the threadlocal maybe leads to an java (or base
>>> library) internal behaviour?
>>>
>>>> BTW: reading the response from Frank Stalherm (in German language)
>>>> is it
>>>> correct you're now seeing the same behavior with the current 2.1.3-dev
>>>> branch?
>>>> In that case I can concentrate on our current version instead of having
>>>> to install/test against 2.1.2.
>>> Yes we see this also on the current 2.1.3-dev branch. The reply of Frank
>>> to the public in fact adds more information: The behaviour was seen
>>> under JS-2.1.2 on IBM 1.4.2 (websphere), JS-2.1.2, JS-2.1.3-dev on Sun
>>> 1.5.0 (tomcat) running on windows, so JDK vendor specific behaviour can
>>> be excluded.
>>>
>>> Regards,
>>> Joachim
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message