>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