tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fernando Padilla <f...@alum.mit.edu>
Subject Re: memory leak on pageValidate
Date Mon, 19 Sep 2005 17:01:46 GMT
great. so... to make sure where are all of the places that caching could
be disabled?  I only know of the system property option.


Howard Lewis Ship wrote:
> I'm very familiar with the code in question; it uses the exact same
> code path as any other page access and is no more likely to leak than
> any other page access .. .unless you are running with caching
> disabled.  Check that first.
> 
> 
> 
> On 9/18/05, Fernando Padilla <fern@alum.mit.edu> wrote:
> 
>>So..
>>
>>Has anyone put Tapestry 4-beta4 on a profiler, and maybe repeatedly hit
>>a url that would throw a PageRedirectException on pageValidate???
>>
>>Well, I have.  And yes, there is a memory leak.  And this ain't good for
>>production systems.
>>
>>
>>I am really tired so tomorrow I can give out more details, but i wanted
>>to send out this email to see if anyone already knew what was going wrong.
>>
>>
>>
>>I haven't taken the time to read the code, but it seems that when
>>pageValidate fails, it causes tapestry to always rebuild the page
>>template of the next page ( like the LoginPage ).  While rebuilding the
>>page template it does a lot of reflection, as well as Binding object
>>creation and somehow that is what is leaked.
>>
>>On one test ( RedHat ), I was getting a leak of
>>sun.reflect.GeneratedMethodAccessor* objects, and a goole search only
>>came up with this: http://www.burnthacker.com/archives/000160.html  So I
>>thought it might be a simple configuration change.
>>
>>But then today I ran a test on a different box ( Gentoo ), and I was
>>getting leaks of the org.apache.tapestry.binding.ExpressionBinding and
>>LiteralBinding objects.
>>
>>
>>
>>So, no matter what is wrong with the VM's reflection classgc settings,
>>Tapestry shouldn't be rebuilding the page template on every request that
>>fails pageValidate.  Conceptually it makes since, if a page in not valid
>>it shouldn't return to the pool, but if that is so then we should not be
>>using it for authorization/authentication checking..
>>
>>
>>
>>any help?  I'll probably start looking through the pageValidate code
>>tomorrow to see if I can track this down..  but I really hope someone
>>else more experience with this code can suggest ideas right away.
>>
>>The second option i have is to not use the pageValidate method at all,
>>and instead do a ServletFilter to manage authorization management..
>>
>>
>>Fernando
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
> 
> 
> 

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


Mime
View raw message