You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Clemens Wyss DEV <cl...@mysign.ch> on 2018/03/03 16:56:21 UTC
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
AW: Blocked Tomcat while (due to?) "concurrent class loading"?
Posted by Clemens Wyss DEV <cl...@mysign.ch>.
>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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Blocked Tomcat while (due to?) "concurrent class loading"?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: Blocked Tomcat while (due to?) "concurrent class loading"?
Posted by Mark Thomas <ma...@apache.org>.
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 <cl...@mysign.ch>
> Gesendet: Dienstag, 6. März 2018 07:51
> An: 'Tomcat Users List' <us...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: Blocked Tomcat while (due to?) "concurrent class loading"?
Posted by Clemens Wyss DEV <cl...@mysign.ch>.
>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 <cl...@mysign.ch>
Gesendet: Dienstag, 6. März 2018 07:51
An: 'Tomcat Users List' <us...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: Blocked Tomcat while (due to?) "concurrent class loading"?
Posted by Clemens Wyss DEV <cl...@mysign.ch>.
>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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Blocked Tomcat while (due to?) "concurrent class loading"?
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org