>Seems like tapestry is doing something funny under the covers, since so >many people seem to be having the same problem.... But of course, >Tapestry is "sitting on top" of a lot of other code (JBoss, hibernate, >etc.... In my case), but it's just too hard to ignore since once >disable-caching=false there is no problem, but when, true, the OOME >occurs.....
When I looked at this in Jan 31 (see archives) the error I ran into was an OOME. When I looked at the actual stack-trace I could see that it was the permanent heap that was out of memory. This is significant since the permanent heap is used for storing classes and types. I have never seen a profiler that analyses the permanent heap in detail - it would be interesting to know if someone knows if such a tool exists. The permanent heap is most probably never garbaged collected, this would amount to throwing away class definitions. This is usually not a problem since an ordinary application has a finite number of classes defined and when they are loaded that is it. Now, when in development mode I assume, and this is just a guess, that Tapestry is enhancing and creating _new_ classes every time a page is loaded. This will fill the permanent heap after a while and when that is full you'll get OOME. When Tapestry can cache the classes it creates the permanent heap will not fill up with new classes and everything should work as expected. So this will only be a problem when in development mode, I wouldn't even consider it a bug in Tapestry (this can happen with JSP compilers also), merely a fact of life as a developer :-) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
