On 06/03/18 09:19, Clemens Wyss DEV wrote: >> 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)?
It will be loaded by the web application class loader and executed in that context. > -----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? That does look like a JVM bug. It might be helpful to post the full thread dump (you should be able to attach .txt file) just so someone can double check it but it sounds like you need to contact your JVM vendor. Mark > >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
