On 6/17/05, Tomas Jucius <[EMAIL PROTECTED]> wrote: > But after a lot of resets jvm memory becomes full, and I get > "java.lang.OutOfMemoryError"
This issue has been raised in a previous thread. It was found that setting the property disable-caching to true would eventually lead to an out of memory exception and that setting the property to false would prevent the exception from occurring. However since you are calling the reset service you are creating the same situation through different means. Here is Johan's original message below summarizing what he found: 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 garbage 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]
