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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
