On 03/03/18 16:56, Clemens Wyss DEV wrote: > 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?
Can't happen. Locking in the class loader ensures that one thread will load the class while the other thread waits. Then both will continue. > Question 2: > is spawning a thread in the initservlet "allowed" at all? It is allowed but it is 'odd'. Normally, you;d expect such threads to be started and stopped by a ServletContextListener. > 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 ... Feels like a JVM issue. You can try using the non-parallel class loader: https://tomcat.apache.org/tomcat-8.5-doc/config/loader.html The full thread dump when the problem occurs would be helpful. Note that the thread dump should tell you if there is a deadlock. If there is no deadlock but you have a thread stuck at the point above that looks very much like a JVM bug. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
