I did take a look at this earlier and didn't see any issues right away. (surprise surprise)
The pooling aspect of components shouldn't have the result that you are having. Ie the pool size might reflect the greatest # of concurrent users you've had at any given instance but shouldn't just incrementally grow and grow. The expression cache isn't doing anything bad though. I did check to be sure and didn't see any indicators of leakage possibilities. This sounds like something I could spend weeks on with only the result of learning more about hivemind/ognl than I'd like. Not sure what to do about it...... On 7/11/06, Steve Shucker <[EMAIL PROTECTED]> wrote:
Sam - I think you're referring to the tomcat PermGen OutOfMemory errors, which doesn't sound like what Henri is describing. But since you've brought it up, a good workaround for the PermGen errors you get when you redeploy is the following flag: -XX:MaxPermSize=128m It's not a solution, but it enlarges the bit of memory that's running out and gives you several more happy deployments. -Steve -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Gendler Sent: Tuesday, July 11, 2006 7:47 PM To: Tapestry users Subject: Re: Re: heap analysis and tapestry caches I certainly don't have any insight into the problem, but even with a fairly simple application, I see Heap Memory errors on a fairly frequent basis. I can redploy the app no more than 2 or sometimes 3 times before I will run out of heap space, and if I use the app for a while, it will just spontaneously combust, even if it is the first deployment. To be honest, the problem makes me VERY nervous, although not yet enough to do any serious invesitgation. --sam On 7/11/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > Don't have an answer for you right now (at least not one that isn't one of > 20 different possibilities), but I'll try and take a peak at the ognl cache > service tonight and make sure I don't see anything that might be holding on > to references when it shouldn't. > > On 7/11/06, Henri Dupre <[EMAIL PROTECTED]> wrote: > > > > Our website based on tapestry 4 seems to be out of memory and is crashing > > every few days no matter what -Xmx I set. It is actually not that bad, > > with > > some scripts we get the website restarted within minutes in case of crash. > > I've been investigating the source of this issue lately using the new Jhat > > and Jmap tools of the JDK 1.6. > > Most of the memory seems to be HashMap$Entry objects which I believe are > > keys to most caches in the app (especially ehcache). > > But what was surprising is the number of instances of tapestry components. > > About 11000 pagelinks and roughly the same amount for IfBean and other > > components after less than 1 day of execution. With jhat I've been able to > > trace the origins of these components and they originate from > > ExpressionBinding (72000 instances). > > I'm not that familiar with the lifecycle of tapestry components but I'm > > curious to understand why has tapestry created so many instances? > > And given the numbers of instances, I'm wondering if Tapestry shouldn't > > have > > limits on its caches? > > Would it improve the memory usage if I use cycle.forgetPage(...) for every > > page? > > > > -- > > Thanks, > > > > Henri. > > > > > > > -- > Jesse Kuhnert > Tacos/Tapestry, team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. > > --------------------------------------------------------------------- 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]
-- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
