1

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!

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!

Gumbo
  • 643,351
  • 109
  • 780
  • 844
Greg
  • 59
  • 2
  • 4

5 Answers5

0

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

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
Joel
  • 29,538
  • 35
  • 110
  • 138
0

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...

Community
  • 1
  • 1
Vincent Ramdhanie
  • 102,349
  • 23
  • 137
  • 192
0

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
  • 17,476
  • 5
  • 50
  • 60
0

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
  • 223,662
  • 58
  • 417
  • 506
0

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 Nowak
  • 7,173
  • 3
  • 53
  • 57