Tomcat being unresponsive and appears to be locked (CAS 7.3.3)
Alex Kauchak
Hello,
We are upgrading CAS from 6.6 to 7.3.3. We deploy a RPM package that wraps the cas overlay war file (with embedded Tomcat) to AWS EC2 instances. We are noticing that Tomcat is not properly responding to requests and seems to be deadlocked on something. Here’s a portion of the thread dump of the tomcat process:
2026-02-17 18:50:08
Full thread dump OpenJDK 64-Bit Server VM (21.0.10+7-LTS mixed mode, sharing):
Threads class SMR info:
_java_thread_list=0x00007f827c004610, length=99, elements={
0x00007f830c02b5a0, 0x00007f830c7e25e0, 0x00007f830c7e3b50, 0x00007f830c7e52e0,
0x00007f830c7e6920, 0x00007f830c7e7ec0, 0x00007f830c7e9a00, 0x00007f830c7eb0c0,
0x00007f830c8be6b0, 0x00007f830c8c0ca0, 0x00007f830c90daf0, 0x00007f830dc5d150,
0x00007f830eb79530, 0x00007f830eb7a5b0, 0x00007f8228bb5980, 0x00007f824030bdf0,
0x00007f822c004a20, 0x00007f8240170ab0, 0x00007f8228bf2b60, 0x00007f82292b7ce0,
0x00007f822c016a90, 0x00007f830ed3a1d0, 0x00007f830ee8e5b0, 0x00007f830ee8d8f0,
0x00007f830ee911d0, 0x00007f830ee92360, 0x00007f830ee934f0, 0x00007f830ee94570,
0x00007f830ee51390, 0x00007f830ee52300, 0x00007f830ee535a0, 0x00007f830ee54850,
0x00007f830ee5dbc0, 0x00007f830edcb610, 0x00007f830edcccd0, 0x00007f8228984a10,
0x00007f82289aa9f0, 0x00007f82289af630, 0x00007f8228afec60, 0x00007f8228affea0,
0x00007f8228b011a0, 0x00007f82289b5300, 0x00007f8228a89850, 0x00007f822c01bf30,
0x00007f830edbb9e0, 0x00007f8270005300, 0x00007f8228b6a390, 0x00007f8228b6bcd0,
0x00007f8228b6c890, 0x00007f8228b6d5c0, 0x00007f8228624870, 0x00007f82286252e0,
0x00007f8228626ee0, 0x00007f82286280d0, 0x00007f8228685d60, 0x00007f8228687450,
0x00007f82286889c0, 0x00007f8228689f30, 0x00007f822868b940, 0x00007f822868d0d0,
0x00007f822868e480, 0x00007f8228e5a8e0, 0x00007f8228e2fe10, 0x00007f8228e30d50,
0x00007f8228e85130, 0x00007f8228e894d0, 0x00007f8228e8a8d0, 0x00007f822840b5a0,
0x00007f8228410c60, 0x00007f8228412940, 0x00007f830fe2e5d0, 0x00007f830fe2fda0,
0x00007f830fe313c0, 0x00007f830fe33da0, 0x00007f830fe51010, 0x00007f822012e320,
0x00007f82480975a0, 0x00007f8254053a90, 0x00007f825007a500, 0x00007f826000afe0,
0x00007f826c4f16f0, 0x00007f82696ad010, 0x00007f8229532eb0, 0x00007f8220294f90,
0x00007f828400f0a0, 0x00007f828003c0c0, 0x00007f82d4002820, 0x00007f822940c1c0,
0x00007f82293a2b70, 0x00007f82e4055120, 0x00007f82340362c0, 0x00007f822040e8d0,
0x00007f823800a970, 0x00007f824401db40, 0x00007f82415076a0, 0x00007f82203acb70,
0x00007f8270003590, 0x00007f827000b900, 0x00007f827c003700
}
"Log4j2-TF-1-AsyncLogger[AsyncContext@5a10411]-1" #20 [93605] daemon prio=5 os_prio=0 cpu=12247.31ms elapsed=10972.85s tid=0x00007f830dc5d150 nid=93605 in Object.wait() [0x00007f8291a11000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait0(java...@21.0.10/Native Method)
- waiting on <no object reference available>
at java.lang.Object.wait(java...@21.0.10/Object.java:366)
at java.lang.Object.wait(java...@21.0.10/Object.java:488)
at com.lmax.disruptor.util.Util.awaitNanos(Util.java:118)
at com.lmax.disruptor.TimeoutBlockingWaitStrategy.waitFor(TimeoutBlockingWaitStrategy.java:47)
- locked <0x00000006051d25d8> (a java.lang.Object)
at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
at com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:156)
at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:122)
at java.lang.Thread.runWith(java...@21.0.10/Thread.java:1596)
at java.lang.Thread.run(java...@21.0.10/Thread.java:1583)
"Log4j2-TF-12-Scheduled-6" #36 [93633] daemon prio=5 os_prio=0 cpu=63.87ms elapsed=10965.76s tid=0x00007f830eb79530 nid=93633 waiting on condition [0x00007f829150c000]
java.lang.Thread.State: TIMED_WAITING (parking)
at jdk.internal.misc.Unsafe.park(java...@21.0.10/Native Method)
- parking to wait for <0x0000000603ded6c8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(java...@21.0.10/LockSupport.java:269)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(java...@21.0.10/AbstractQueuedSynchronizer.java:1797)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java...@21.0.10/ScheduledThreadPoolExecutor.java:1182)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(java...@21.0.10/ScheduledThreadPoolExecutor.java:899)
at java.util.concurrent.ThreadPoolExecutor.getTask(java...@21.0.10/ThreadPoolExecutor.java:1070)
at java.util.concurrent.ThreadPoolExecutor.runWorker(java...@21.0.10/ThreadPoolExecutor.java:1130)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(java...@21.0.10/ThreadPoolExecutor.java:642)
at java.lang.Thread.runWith(java...@21.0.10/Thread.java:1596)
at java.lang.Thread.run(java...@21.0.10/Thread.java:1583)
We’re unable to figure out what is causing this to occur. Has anyone encountered anything similar? Where could we look to try and get more details? Thank you!