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 Mon, 26 Nov 2007 21:23:51 GMT
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


Mime
View raw message