Java – how do I deploy my war on Tomcat for so long?

I have a web application that usually takes a lot of time to deploy on Tomcat I suspect that a database connection is waiting for timeout, but this is just a guess. I want to determine what caused the blocking, so I can solve this problem Can anyone suggest that I do this? Should I check Tomcat and look for clues when loading war? If so, is a tutorial somewhere good for beginners?

If this is important, my web application uses spring and hibernate A colleague told me that this may slow down because they are so large that a class loader is suffocating the large number of classes it needs to load

I also see this when I stop Tomcat or hot deploy war to Tomcat that is already running:

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

Maybe that's part of the problem? Redeploying my web application almost always needs to restart Tomcat. I always think the jdbc driver problem mentioned above is the culprit, but maybe it is also related to the slow startup time?

I know very little about such things, so this is a real opportunity to learn Thank you for your help

Solution

You can use an analyzer, but it's a little too much Instead, only a small number of thread dumps are required when the application loads You can use jstack or jvisual VM, and there are a lot of resources on the web describing how to do this Basically, you need a Tomcat PID (see: JPS)

If you find it difficult to analyze a thread dump – add it to your problem Usually, it's easy to find bottlenecks Typical problems:

>Applications try to get some resources from Internet mode > scan many classes on classpath > too many GCS (just in case of GB logging) > out of memory (swap, see iostat / iotop)