Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)

[Dave Greggory <da...@yahoo.com>]

Yes, we're using a the Uber-component pattern as you put it. As that is the only way, we can build a dynamically defined Page. 

Right now, we have about 8 pages, containing possibly 12 Layout components, and 29 functional components, some of which a Form Components. And those contain 4 possible Form Layouts and 13 possible Form Sub Components. A database based configuration defines what components and layouts are active or shown on each page. We have separate CMS like management system to update / edit this page configuration. 

Is there a different way we can accomplish the same thing? We need to maintain the flexibility to dynamically determine where in the page a component is added to or shown at all. 

I don't quite understand what you mean by how the BeanEditForm component works. Perhaps someone can kindly explain it to me. Thanks so much.



----- Original Message ----
From: Howard Lewis Ship <hl...@gmail.com>
To: Tapestry users <us...@tapestry.apache.org>
Sent: Friday, September 11, 2009 2:36:00 PM
Subject: Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce  after forced GC)

Tapestry 5.1.0.5 is more efficient, but that's mostly in terms of reducing
the number of temporary objects created during a single request.
392,000 instances of ComponentPageElementImpl?

How many pages in your application?  Say there's 15 distinct pages.

392,000 / (15 district * 10 hard limit) =  2600 components per page

In fact, looking at the memory, there's 25 PageImpls, so now we're talking
15,680 components / page! That seems like a lot!

I'm concerned you've fallen prey to the Uber-component anti-pattern.

If you have a component that contains, in its template, 10 other components
then every time you use such a component, that's 10 instances of
ComponentPageElementImpl.

I've seen systems that, for every field to be edited, an Uber-component is
used, and the Uber-component is set up to edit any type of data, so it has a
TextField, a Select, a Checkbox ... and a Grid containing a bunch of other
stuff ... and so on.  Thus editing the userId field of the User object
claims several hundred components (instances of ComponentPageElementImpl).

If you notice how BeanEditForm / BeanEditor / PropertyEditor works, the
actual editing components live on a secondary page.  An instance of
PropertyEditor is just the one ComponentPageElementImpl instance, plus
shared "off screen" components from the PropertyEditBlocks page (part of
Tapestry's core library).

If you have ten PropertyEditor components on a page, that's 10
ComponentPageElementImpl instances, not hundreds or thousands, even though
there are dozens of components on the PropertyEditBlocksPage.

Anyway, perhaps this is what you've done, or perhaps there's some other
issue ... some cache or pool (outside of Tapestry) that is holding onto page
instances even after Tapestry has discarded them. Or perhaps the memory
issue is not related to Tapestry after all (though that 392,000 instances
seems troublesome).


On Fri, Sep 11, 2009 at 8:47 AM, Dave Greggory <da...@yahoo.com>wrote:

> I have T5.0.18 running in Tomcat 5.5 with Java 1.5 32-bit  -Xms2048m
> -Xmx2048m  -XX:PermSize=128m  -XX:MaxPermSize=128m.
>
> Configured as:
>    tapestry.page-pool.active-window = 5 m
>    tapestry.page-pool.hard-limit = 10
>
> Ran a JMeter Load Test with
>    10 concurrent users
>    Ramp-up time of 60 seconds
>    1 second between requests for a particular user
>    Repeated 20 times
>
> The user will visit a signup page, submit a form, then get redirected to a
> billing page, submit that with CC info and be shown a thank you receipt page
> and will log out. During the test, memory usage went from around 400MB to
> 1.5GB. Did a forced GC from JConsole and it did not release more than 100MB
> at most. Re-ran the above test with 20 users instead with the same config
> (no re-starting of Tomcat) and the memory usage climbed to about 2GB (max
> Xmx) and eventually Tomcat stopped responding. After 30 minutes or so, it
> finally threw an OOM with a memory dump.
>
> JConsole Memory Usage
> http://img41.imageshack.us/img41/5303/tapestryloadtestmemoryu.jpg
>
> HPROF Memory Dump in YourKit:
> http://img38.imageshack.us/img38/431/memorydumpclasslist.png
>
> What's going on here?
>
> Just some info on our app. Our pages are similar to a CMS system, except
> that instead of static content, we serve up different components (forms,
> etc) for users. We use a Dispatcher and overriden LinkFactory to map
> seo-optimized URLs to a given Page. Many different URLs may map to the same
> page and the same URL may map to more than 1 page based on user's status. A
> given page will have multiple layouts injected into it, and each layout will
> have multiple components injected into it (it goes a little bit deeper than
> that). At runtime, a page configuration is read from the database based on
> the URL and user's status, and the relevant layouts and components to show
> are selected. Since Tapestry is limited in the way that it can only use a
> component that has already been injected to the page (ie. IoC can't
> dynamically load a component without having being referenced in the page
> before), each page can load a multiple different components.
>
> I can understand if this complex scenario needed a couple of hundred megs,
> but 2 GB? And even more worrisome, why does it not collect during garbage
> collection? During the whole test of 20 minutes or so, more than 6 minutes
> were spent in GC.
>
> Any ideas? Thoughts?
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>


-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to learn
how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com



      


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