tags:

views:

90

answers:

6

I'm running TC 6 in "development mode", eg. the application classes are changing constantly and I want to see the latest version with minimal hassle.

For a while I was using the TC HTML 'manager' application to reload; this worked up to a point, but I kept getting OOM errors after a while. Surfing suggested that TC has a leak when reloading this way. Plus it was a hassle, the extra step after compiling every time.

So I switched to setting 'reloadable true' in the context.xml file. This worked up to a point and didn't require any extra steps, but again I keep getting OOM errors (less frequently, but still many times a day). More surfing suggests that there may be TC leaks in here also.

If I run the app with 'reloadable true' but don't recompile anything, or with 'reloadable false', it runs forever (and VisualVM thinks it is OK memory-wise).

So I am kind of coming to the conclusion that every time I recompile a class I should fully restart TC. This is a huge pain but maybe better than random periodic OOM crashes. Just wondered if anyone had any better ideas. Maybe I should try a different container.

Cheers and thanks!

A: 

Tomcat class reloading used to be buggy - and the OOM is the manifestation of that. Jetty is much more reliable in this regard.

Joel
A: 

You might find this question useful. I remember seeing a question here that suggested using jRockit to solve this issue but I cannot remember where...I'll search and update this answer when I find it.

Actually it was JRebel which promises to solve this problem. I haven't used it myself so I can't say how valid the claim is but I am considering it...

Vincent Ramdhanie
A: 

We ended up with scripts to just redeploy in Tomcat - build from source control, shut down tomcat, remove stale files from tomcat, deploy new war, restart tomcat, check tomcat logs for errors.

Otherwise we got the memory issues.

JeeBee
A: 

Do you have anything special in your application - e.g. starting your own (non daemon) threads, or using libraries which does so ? Atleast in that case you get leaks.

I'm developing using eclipse, having tomcat managed by eclipse for development. Tomcat auto reloads the application after every compile - I've not yet experienced any memory growth or leaks, nor when I have a setup for developing against a remote tomcat devel server - deploying the app from an ant script. Allthough it did leak when I started using java.util.concurrent.Executors which(by default) creates non-daemon threads.

nos
A: 

Thanks a lot for the responses. JRebel looks like a great plan, I will try that; it appears to be designed specifically to solve this problem, which suggests that I am not making it up, and it's cheap enough that if it's a scam, no big deal.

The app does a few simple, standard MySQL calls via ConnectorJ, and the default out of the box memory allocation. Frankly though I don't see how either of these things are relevant, since the app behaves fine as long as no reloading occurs.

Thanks again. Once again, I can't believe how useful SO is!

Greg
Why not indicate your gratitude by upvoting and/or accepting some answers?
Don
A: 

Here is example how to use JRebel and JSF http://przemek-nowak.pl/2010/10/jrebel-czyli-jak-przyspieszyc-prace-programisty/, may be useful to someone.

przemek