portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: JetspeedEngine bound to threadlocal?
Date Mon, 26 Nov 2007 22:43:19 GMT
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


Mime
View raw message