How can I find out what's taking my WAR so long to deploy on Tomcat?
hibernate, java, profiling, spring, tomcat
Solution
You can use a profiler, but it is a bit of an overkill. Instead just make few thread dumps while the application loads. You can use `jstack` or `jvisualvm`, plenty of resources over the net describing how to do this. Basically you need a PID of your Tomcat (see: `jps`).
If you find it hard to analyse the thread dump - add it to your question. Typically it's pretty easy to find a bottleneck. Typical problems:
- the application tries to fetch some resource from the Internet like XML schema
- a lot of classes to scan on the CLASSPATH
- excessive GC (enable verbose gc logging just in case)
- not enough memory (swapping, see `iostat`/`iotop`)
Problem
I have a web application which often takes an inordinate amount of time to deploy on Tomcat. My suspicion is that there's a database connection somewhere that's waiting until a timeout, but that's just a guess and I want to find out for sure what's causing the hold up so I can remedy the issue. Can anyone suggest a way I can go about doing this? Should I profile Tomcat when it's loading the WAR and look there for clues? If so is there a tutorial somewhere that's good for a beginner? In case this matters my web application uses Spring and Hibernate. I've been told by a colleague that perhaps these are causing the slow down in that they are so huge that somewhere a class loader is choking on the sheer number of classes it needs to load. Also I see this when I stop Tomcat or hot deploy the WAR to an already running Tomcat: ``` Jun 1, 2012 6:03:33 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc SEVERE: The web application [/nacem-rest] registered the JDBC driver [oracle.jdbc.OracleDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered. Jun 1, 2012 6:03:34 PM org.apache.catalina.startup.HostConfig deployWAR ``` Perhaps this is part of the problem? Redeploying my web application almost always requires a restart of Tomcat as well, and I've always assumed that the above mentioned JDBC driver issue was to blame, but maybe it also has something to do with the sluggish start time as well?