Possible root causes include a too low setting for -Xss and illegal cyclic inheritance dependencies

Question

My app is quit big and using many jars and tools. Platform - windows 2008 server, Spring , hibernate, Quarts, mysql, tomcat-7.35

When I deploy and start the server first

Answer 1

The stack trace says that tomcat is running out of stack space on the thread that is scanning your application looking for java based servlet configurations. There are three ways you can solve this problem.

• Increase the stack size -Xss4m
• Tell Tomcat not to scan your application if you are not using any java based Servlet configuration add metadata-complete="true" to your web-app in web.xml
• Restrict what jar files tomcat scans. see http://tomcat.apache.org/tomcat-7.0-doc/config/jar-scanner.html

Update 1

you need to pass -Xss4m to your jvm to set the stack size, -Xss10m would set it to 10mb.

I am using Hibernate and Spring in my application too with annotations, the scanning that tomcat does is to look for Servlet 3.0 annotations so you can still restrict things while using hibernate and spring annotations, since hibernate and spring annoations are scanned for by spring and hibernate.

If you are running tomcat as a windows service you will need, to pass the arguments via procrun since that is the executable that is launching the jvm. The docs for procrun are at http://commons.apache.org/daemon/procrun.html. tomcat7.exe is really procrun.exe renamed, which means that all your jvm options are written to the registery under

The basic Service definitions are maintained under the registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\

Additional parameters are stored in the registry at:

HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\ProcRun 2.0\\Parameters

On 64-bit Windows procrun always uses 32-bit registry view for storing the configuration. This means that parameters will be stored inside:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\ProcRun 2.0\

Update 2

Tomcat has been tweaking how the scanner works between point releases. try rolling forward through the versions 7.25,7.26 ... etc to find the version at which it breaks, the go through the release notes for that version to see if they changed how the scanner works.

Another thing you can try doing, is to create another war file which has all the third party jars in your WEB-INF\lib but not your code. See if you get that error if you start up, and if you do then should file a bug report with tomcat and make available to them your sample project that replicates the problem, on github or some other free code hosting system. I am sure if there is a bug they will fix it.