13

I'm looking for a hint how to make tomcat CI ready or an servlet container / application container which stand often redeploys like they happen when using hudson ci.

I experienced that Tomcat 6 does not properly undeploy webapps, leaving classes in jvm.

For example I monitored tomcat 6 with VisualVM: on start 2000 classes, on deploy of an app 3000 after redeploy 4000 and redeploy 5000 classes and so on - leading to crashes, memory leaks...

Okay hope one have a hint on tomcat and continuous-integration or other app servers.

Robert Munteanu
  • 67,031
  • 36
  • 206
  • 278
jpse
  • 229
  • 2
  • 9
  • I would *love* to see answers to this as well. We've had similar issues with PermGen memory errors, etc. with our CI autodeploys to Tomcat 6. – Pete Mar 12 '10 at 22:55
  • Running the latest tomcat version ? It has more error logging as to what isn't properly cleaned up on context reload. If you use mysql, get the connector/j 5.1.12, as it fixes a thread leak, which causes huge reload leaks in tomcat. – nos Mar 13 '10 at 01:50
  • We use small apps without mysql or connectors. Small example apps from spring, simple hello world jsp aps and so on. – jpse Mar 13 '10 at 12:41
  • NOTE: tested on tomcat 6.18, Tomcat 6.24 , tomcat 6.26 – jpse Mar 14 '10 at 14:00
  • Seems Tomcat and Hudson have some problems as the hudson team advises here:http://wiki.hudson-ci.org/display/HUDSON/Tomcat Seems Tomcat is not ready for CI when using the versions 6.0.21 - 6.0.26 and hudson further reading: http://issues.hudson-ci.org/browse/HUDSON-6473?focusedCommentId=138461&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_138461 https://issues.apache.org/bugzilla/show_bug.cgi?id=44041#c12 – jpse Jun 16 '10 at 08:55
  • I end up with installing hudson standalone and restarting tomcat after deployment. So I think I answered the question. Thanks for all contributions. – jpse Jun 28 '10 at 15:55

3 Answers3

7

Update : I've performed some tests with a moderately complex web application using Spring, Hibernate, GWT, C3P0 and HsqlDB.

Stock Tomcat 6.0.24 works just fine , provided you use the client compiler. It works on ten redeploys, whereas the server compiler breaks down on the fourth. I suggest you try with the -client flag.

Trying to debug the usage of the server compiler was fruitless, as the Eclipse MAT showed no GC roots for the classloaders, and yet they were retained. An oft-referenced bug , PermHeap bloat in and only in server VM was reportedly fixed in Java 6 update 16, but my tests fail with Java 6 update 16.

Tomcat has been checked and double-checked for such memory problems, and quite often the applications were to blame. No that is not to say that it's necessarily hard to have such a perm gen leak.

There are two possibilities here:

If you actually want to debug this problem and make sure that it's Tomcat's fault, you can you the Eclipse memory analyser. They have a good blog post explaining how to debug PermGen problems.

Community
  • 1
  • 1
Robert Munteanu
  • 67,031
  • 36
  • 206
  • 278
  • Hi, you said GCC is broken... What do you exactly mean by that. Is there any test? anyway, yes indeed application often causing the trouble, thats why we use sample apps like they uses million times. The new leak detection feature unfortunately not solving the problem but is a nice step in the right direction and helping hand to understand whats going on... – jpse Mar 14 '10 at 14:03
  • Yes, the GCC reference is quite opaque, sorry. What I mean to say is that we as developers have a tendency to blame other components - application server, OS, cosmic rays :-) for problems which we can't explain and . I've done this too many times, and almost always found the fault in my code. – Robert Munteanu Mar 14 '10 at 19:13
  • @Robert You are digging deep, what do you meean excatly with use the client compiler, where to set that flag? – jpse Mar 23 '10 at 17:58
  • @Phillip: the client compiler is selected when you pass the `-client` argument to the java invocation. For Tomcat this can be set in `CATALINA_OPTS`. – Robert Munteanu Mar 23 '10 at 20:50
  • @Robert I tested the -client flag in windows and linux environment, both with no impact... – jpse Apr 14 '10 at 16:58
  • @Phillip : then your only solution is to use the Memory Analyser ( or a commercial profiler) and see where the leak is. It might be Tomcat or it might be your applications. – Robert Munteanu Apr 15 '10 at 08:41
1

I always like to take drastic measures to make sure that everything is clean and in a fully reproducible state when starting

1) kill tomcat

2) delete it from disk

3) unzip a clean version

4) overwrite your personalized modified configured files

5) restart tomcat

6) deploy your app

flybywire
  • 261,858
  • 191
  • 397
  • 503
  • Thanks, we've use fresh clean tomcat for tests, no tinkering applied, thats not exactly the point... – jpse Mar 14 '10 at 13:41
  • While this is the "safest" approach, it will also be much more cumbersome to set up, especially if you have multiple Tomcat servers udpate by CI (dev, alpha, preproduction etc.). Why did you feel these drastic measures to be necessary (esp. the Tomcat reinstall)? – sleske Jul 29 '11 at 08:38
-1

Take a look at Apache Cactus - it's a framework for server-side in-container unit testing. It works pretty much with any servlet container.

Slava Imeshev
  • 1,360
  • 10
  • 14
  • While Apache Cactus is interesting, I don't see how this relates to the question, which is about problems caused by frequent re-deployments. – sleske Jul 29 '11 at 08:39