Thanks for the link. As I said before, I don't think that we've fallen prey to that exactly. Doing some local testing and looking at one of our largest pages which displays search results, it has 76 component objects, each of those will have components nested within (pretty heavily in some cases) but nothing which has a bunch of components where only one is used and the others are redundant. (what I think is this uber-component thing)
It looks like explicit repeated use of a component, rather than using a single component in a loop, creates a lot more component objects in the heap. I've never seen anything warning against this, and we do usually use loops but it's not always the best solution. Again, looking at our results page, a single instance seems to get 11,283 ComponentPageElementImpl instances created for it. I'm finding it hard to find a good view of the tree to figure out what component(s) are the main culprits for this huge number of instances. Thanks for any help or guidance you can give me. Andy > -----Original Message----- > From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com] > Sent: 20 April 2010 15:56 > To: Tapestry users > Subject: Re: Tapestry using 1.3Gb of heap space after capacity testing > > On Tue, 20 Apr 2010 11:41:25 -0300, Blower, Andy > <andy.blo...@proquest.co.uk> wrote: > > > Uber-component anti-pattern, not to my knowledge, but we have a lot > of > > pages and components now. And a lot of logic in them. The project's > > large enough I can't be sure. Do you have a handy link to Howard's > > description so I can get my team to check? > > It's here: > http://old.nabble.com/-T5.0.18--Out-of-Memory-Error---Potential-Leak- > (doesn't-reduce-after-forced-GC)-to25403474s302.html#a25497441 > That thread is interesting, by the way. The problem is more about how > components and pages are written than the number of them. > What Tapestry version are you using? > > > Page pool config is default, I don't know enough to fiddle yet. Also, > > the test is on a single stand alone server with no clustering, we are > > using Tomcat clustering for production. > > You should take a look a them, as they can affect the memory > consumption > directly. > > > I did fire the GC manually before getting concerned BTW. A lot of > heap > > seems to be taken up with 100-300k descriptions on the > > InternalClassTransformationImpl class. An example of one is attached > > below - seems wrong to me and more like the debug that can be > requested > > through log4j rather than a description. > > They look really bigger than they should. 300k is a lot. I have one > application with a reasonable number of pages and components and it > runs > inside a 512 MB slide at SliceHost without using the whole memory. > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, > developer, > and instructor > Owner, software architect and developer, Ars Machina Tecnologia da > Informação Ltda. > http://www.arsmachina.com.br > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org >
