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