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 Tue, 20 Sep 2005 00:13:25 GMT
Right but it looks like it's unbounded/unmanaged.  The number of
instances keeps going up until we run out of memory and the systems crash.


On one test the number of HomePage and LoginPage instances is going up.
 At one time we had 293 instances;  1 hr 27 min later we had 888.



All that was happening between the two memory snapshots was this script,
which sleeps for *5* seconds between requests.

#!/bin/tcsh
while ( 1 == 1 )
wget -O app "http://ruth:8080/protrade-support-site-3.0/app"
echo sleeping for 5 [`date`]
sleep 5
end



What that did was try to access the HomePage, which then pageValidate
throws a PageRedirectException to the Login page; like so:

LoginPage login = cycle.getPage( "Login" );
login.activateExternalPage( callback to current page );
throw new PageRedirectException( login );


The memory usage is corelated to the number of requests per second.
With a *1* sec sleep between each of the above requests, the memory rate
is 60Mb/17min or about 3Mb/min.  That means that we would run out of
memory in one or two hours, under normal load.






Howard Lewis Ship wrote:
> But remember that, if you are stress testing Tapestry, you'll be in
> situations where Tapestry has to create multiple instances of the same
> page.  Reading the XML spec occurs once, creating the enhanced class
> occurs once, parsing the template occurs once, but assembling it all
> together may occur many times.
> 
> On 9/19/05, Fernando Padilla <fern@alum.mit.edu> wrote:
> 
>>Alright.  I need a sanity check.  Could someone please double check my
>>beliefs:  Are the following true or false.
>>
>>
>>1) Caching is disabled by setting the approriate system property.  And
>>only through that means.
>>
>>
>>2) Deprecated component warnings are printed out only when a page
>>template is reconstructed, not on every page render.
>>
>>
>>
>>
>>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
>>
>>
> 
> 
> 

---------------------------------------------------------------------
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