Re: AW: Blocked Tomcat while (due to?) "concurrent class loading"?
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 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 CB > [ 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
AW: Blocked Tomcat while (due to?) "concurrent class loading"?
>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 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 CB [ 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
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 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
AW: Blocked Tomcat while (due to?) "concurrent class loading"?
>What about the storage-mechanism? Maybe you have something like an NFS share >storing the JAR file and you have a problem with the network connection? no NFS in use. Ext4 only -Ursprüngliche Nachricht- Von: Christopher Schultz <ch...@christopherschultz.net> Gesendet: Montag, 5. März 2018 20:26 An: users@tomcat.apache.org Betreff: Re: Blocked Tomcat while (due to?) "concurrent class loading"? -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/5/18 8:27 AM, Mark Thomas wrote: > 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.ja va:76) >> >> at ch.mysign.cms.commons.TorqueUtil.getTableName(TorqueUtil.java:2756) >> at >> ch.mysign.cms.security.AccessTableConfig.setPeerClassName(AccessTable Config.java:82) >> >> at sun.reflect.GeneratedMethodAccessor605.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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. What about the storage-mechanism? Maybe you have something like an NFS share storing the JAR file and you have a problem with the network connection? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqdmc4dHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFgKHBAAlBA+C4b0NAHO5fdR Qc/ihDxfM2E/AfuCwX3s/i/MyqlsOANSD1dn37OWStG38InasDMNetKp4+AYm3PI o8eK1LeF8qMX0b/pilGY8BiWTtvYnV+0+vUwW8fQ6FZeiJMyyA+fiuLnvvOHM8j5 cYVBsJBOkp1BrRg+ILpBfOjjLqldMpAg1C3MOwScZUdB0E0tYF5BkCNXUUcxwl+8 3VhUYIttBbYBYoU2I4dqxTD24wb+sIKLGdLpsxvI8CzworRiAT/gYPMnaU2m5hgJ E1cRbkTXohgX4IweYAJQfITHXAE9hoMBtvOxuSqRUuNM7CD8yItfOEt5LyixSN38 QGxgV98PgW+mUlgsRNBCZaki74cUuxvbGmH6mylx8iDNj8sFUMhvgh6bkYeJzgek J73iYM/KJOsPFTRqryQtiqxH8eik7shjjyd9/p2lfTy9dzFct4T+Raz8l7K3M5tK nKpeFq2BEVJhHTU7pcHJLlybl5olDWO5h3t5e9/SvUonGPnRpsPuBxmv1E5b/kki gDMdZKtIJQ2VULueN+mriIMtY2qN5tBEY+AygvK150qxeoVZrh+ZLkYCRX0qficy D1fQiyAtK3FeUCedSpVlte1AXQIFdnQAXdU6UXT1B+NYRtUndrW+KQjekkDrkPNi oe9krB2/pZ6R3D2GZ2nCjcyOyFU= =zAaE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Blocked Tomcat while (due to?) "concurrent class loading"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/5/18 8:27 AM, Mark Thomas wrote: > 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.ja va:76) >> >> at ch.mysign.cms.commons.TorqueUtil.getTableName(TorqueUtil.java:2756) >> at >> ch.mysign.cms.security.AccessTableConfig.setPeerClassName(AccessTable Config.java:82) >> >> at sun.reflect.GeneratedMethodAccessor605.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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. What about the storage-mechanism? Maybe you have something like an NFS share storing the JAR file and you have a problem with the network connection? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqdmc4dHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFgKHBAAlBA+C4b0NAHO5fdR Qc/ihDxfM2E/AfuCwX3s/i/MyqlsOANSD1dn37OWStG38InasDMNetKp4+AYm3PI o8eK1LeF8qMX0b/pilGY8BiWTtvYnV+0+vUwW8fQ6FZeiJMyyA+fiuLnvvOHM8j5 cYVBsJBOkp1BrRg+ILpBfOjjLqldMpAg1C3MOwScZUdB0E0tYF5BkCNXUUcxwl+8 3VhUYIttBbYBYoU2I4dqxTD24wb+sIKLGdLpsxvI8CzworRiAT/gYPMnaU2m5hgJ E1cRbkTXohgX4IweYAJQfITHXAE9hoMBtvOxuSqRUuNM7CD8yItfOEt5LyixSN38 QGxgV98PgW+mUlgsRNBCZaki74cUuxvbGmH6mylx8iDNj8sFUMhvgh6bkYeJzgek J73iYM/KJOsPFTRqryQtiqxH8eik7shjjyd9/p2lfTy9dzFct4T+Raz8l7K3M5tK nKpeFq2BEVJhHTU7pcHJLlybl5olDWO5h3t5e9/SvUonGPnRpsPuBxmv1E5b/kki gDMdZKtIJQ2VULueN+mriIMtY2qN5tBEY+AygvK150qxeoVZrh+ZLkYCRX0qficy D1fQiyAtK3FeUCedSpVlte1AXQIFdnQAXdU6UXT1B+NYRtUndrW+KQjekkDrkPNi oe9krB2/pZ6R3D2GZ2nCjcyOyFU= =zAaE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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.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
Blocked Tomcat while (due to?) "concurrent class loading"?
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