From time to time we encouter tomcats which block while starting up. The stacktraces of the then "running" (but effectively blocked) threads (one of them being the init servlet starting thread) look alike: ajp-nio-8059-exec-8 Stack Trace is: java.lang.Thread.State: RUNNABLE at java.lang.Class.forName0(Native Method) <-- STAYS HERE FOREVER at java.lang.Class.forName(Class.java:264) at ch.mysign.cms.commons.ReflectUtil.getClassForClassName(ReflectUtil.java:76) at ch.mysign.cms.commons.TorqueUtil.getTableName(TorqueUtil.java:2756) at ch.mysign.cms.security.AccessTableConfig.setPeerClassName(AccessTableConfig.java:82) at sun.reflect.GeneratedMethodAccessor605.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ...
i.e. there seems to be class loading ongoing. Unfortunately I cannot provide code that reproduces this (mis)behavior/bug. I can say though that the -XX:+AlwaysLockClassLoader JVM option "helps". Question 1: what happens if the init servlet spawns a thread and by coincidence (timing issue?) at the "very same time" the init servlet thread and the spawned thread try to load a (possibly even the same?) class? Question 2: is spawning a thread in the initservlet "allowed" at all? Context/environment: Debian Stretch JDK 1.8.0_162 Tomcat 8.5.28 To be noted: weh ad this "issue" with/in other environments too (even on Win10) ... Sorry for being so "fuzzy" but that's all we have to tell 😉 We can live for the moment with the AlwaysLockClassLoader-flag, but nevertheless would like to know if this is a bug or if we are doing something wrong ... Thx in advance! -Clemens
