>you;d expect such threads to be started and stopped by a ServletContextListener I guess the ServletContextListener is being called/executed from/by another thread than the startStop-thread (and hence has another classloader)?
-----Ursprüngliche Nachricht----- Von: Clemens Wyss DEV <clemens...@mysign.ch> Gesendet: Dienstag, 6. März 2018 07:51 An: 'Tomcat Users List' <users@tomcat.apache.org> Betreff: AW: Blocked Tomcat while (due to?) "concurrent class loading"? >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. The stacktraces indicate no deadlock, nevertheless the JVM is "blocked". Should I attach or copy&paste a stacktrace? > you;d expect such threads to be started and stopped by a > ServletContextListener. Thx, we'll do this -----Ursprüngliche Nachricht----- Von: Mark Thomas <ma...@apache.org> Gesendet: Montag, 5. März 2018 14:28 An: users@tomcat.apache.org Betreff: Re: Blocked Tomcat while (due to?) "concurrent class loading"? 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.jav > a:76) at > ch.mysign.cms.commons.TorqueUtil.getTableName(TorqueUtil.java:2756) > at > ch.mysign.cms.security.AccessTableConfig.setPeerClassName(AccessTableC > onfig.java:82) at > sun.reflect.GeneratedMethodAccessor605.invoke(Unknown Source) at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess > orImpl.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 B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB [ X ܚX KK[XZ[ \ \ ][ X ܚX P X ] \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ \ \ Z[ X ] \X K ܙ B --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
