Yep. That would be a suicide to have caching disabled. In fact I already have caching turned on while "readiness" testing. But I'm wondering if you guys know of an efficient way to deal with this while in developement?
Adam On 3/30/06, Geoff Longman <[EMAIL PROTECTED]> wrote: > Tap caching is a development time only device and has know problems > like OOMEs. You should not deploy an application to a production > server with caching disabled. > > Geoff > > On 3/30/06, Adam Zimowski <[EMAIL PROTECTED]> wrote: > > Mornin' again. > > > > So I'm finally done with coding initial version of my app. I've > > survived countless OOEM's after hot-redeploys of my app during > > developement (I had caching disabled of course), but I knew about > > those OutOfMemoryExceptions from numerous thread posts here and > > elsewhere on the net. Now that I'm "readiness" testing my app with > > caching enabled, the app is rocking like a speed daemon, and OOEM's > > are gone. That's nice, the issue will come up when I start coding 0.2. > > One guy summarized this problem pretty well: > > > > Quoting "musson.michael at gmail.com" : > > > 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 Smile > > > > Now, for my initial version 0.1 I was able to put up with it without > > much annoyance because the app is still fairly small. I can see this > > being a major problem as my app grows, because developement will > > become a lot harder due to this problem. > > > > So my question to you guys is, how do you deal with this? Is it a > > Tapestry "feature" or my Servlet container bug? I'm using Tomcat 5.0 > > and I'm planning on upgrading to Tomcat 5.5 after releasing my app as > > I know Tomcat has some issues of its own. > > > > Regards, > > Adam > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > The Spindle guy. http://spindle.sf.net > Blog: http://jroller.com/page/glongman > Other interests: http://www.squidoo.com/spaceelevator/ > > --------------------------------------------------------------------- > 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]
