Thread dump running Classic JVM(jdk 1.2.2)

Hi,
We get a thread dump while running our application. The application is in java/jsp running on apache-tomcat. The tomcat version is 3.2.1. Java version being used is:
java version "1.2.2"
Classic VM (build JDK-1.2.2-007, native threads, symcjit)
Does anyone have any idea how to identify the reason for the thread dump? The application eventually hangs after the thread dump. Thanks in advance. Below is the dump:
<pre>
Full thread dump Classic VM (JDK-1.2.2_007, native threads):
"Thread-34" (TID:0x5faa550, sys_thread_t:0x2f4158, state:CW, native ID:0xb9c) prio=5
"Thread-33" (TID:0x5faa1d0, sys_thread_t:0x22092f98, state:CW, native ID:0xa54) prio=5
     at java.lang.Object.wait(Native Method)
     at org.apache.tomcat.util.ThreadPool$MonitorRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-32" (TID:0x5faa220, sys_thread_t:0x2207df88, state:R, native ID:0xb18) prio=5
     at java.net.SocketInputStream.socketRead(Native Method)
     at java.net.SocketInputStream.read(SocketInputStream.java, Compiled Code)
     at org.apache.tomcat.service.connector.TcpConnector.receiveFully(TcpConnector.java, Compiled Code)
     at org.apache.tomcat.service.connector.TcpConnector.receive(TcpConnector.java, Compiled Code)
     at org.apache.tomcat.service.connector.Ajp13ConnectionHandler.processConnection(Ajp13ConnectionHandler.java, Compiled Code)
     at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java, Compiled Code)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-31" (TID:0x5fa9e48, sys_thread_t:0x22080228, state:CW, native ID:0xb2c) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java, Compiled Code)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-30" (TID:0x5fa9e98, sys_thread_t:0x22080140, state:CW, native ID:0x908) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java, Compiled Code)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-29" (TID:0x5fa9ee8, sys_thread_t:0x2207e758, state:CW, native ID:0x74c) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java, Compiled Code)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-28" (TID:0x5fa9f38, sys_thread_t:0x22080518, state:R, native ID:0x2fc) prio=5
     at java.net.PlainSocketImpl.socketAccept(Native Method)
     at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:414)
     at java.net.ServerSocket.implAccept(ServerSocket.java:242)
     at java.net.ServerSocket.accept(ServerSocket.java:224)
     at org.apache.tomcat.service.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:286)
     at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java, Compiled Code)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-27" (TID:0x5fa9b58, sys_thread_t:0x2207ff00, state:CW, native ID:0xa7c) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-26" (TID:0x5fa9ba8, sys_thread_t:0x2207fd90, state:CW, native ID:0xa70) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-25" (TID:0x5fa9bf8, sys_thread_t:0x2207fb78, state:CW, native ID:0x4d4) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-24" (TID:0x5fa9ca0, sys_thread_t:0x2207f8f0, state:CW, native ID:0x7c8) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-23" (TID:0x5fa9c98, sys_thread_t:0x22055c18, state:CW, native ID:0xa60) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-22" (TID:0x5fa94a0, sys_thread_t:0x220556a0, state:CW, native ID:0x68c) prio=5
     at java.lang.Object.wait(Native Method)
     at org.apache.tomcat.util.ThreadPool$MonitorRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-21" (TID:0x5fa94f0, sys_thread_t:0x220555b8, state:R, native ID:0xb24) prio=5
     at java.net.PlainSocketImpl.socketAccept(Native Method)
     at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:414)
     at java.net.ServerSocket.implAccept(ServerSocket.java:242)
     at java.net.ServerSocket.accept(ServerSocket.java:224)
     at org.apache.tomcat.service.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:286)
     at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java, Compiled Code)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-20" (TID:0x5fa9540, sys_thread_t:0x22055448, state:CW, native ID:0x664) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-19" (TID:0x5fa9590, sys_thread_t:0x22055360, state:CW, native ID:0x5c0) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-18" (TID:0x5fa9338, sys_thread_t:0x220551f0, state:CW, native ID:0x874) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-17" (TID:0x5fa9388, sys_thread_t:0x22055080, state:CW, native ID:0x4f4) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-16" (TID:0x5fa9480, sys_thread_t:0x22064cf8, state:CW, native ID:0x814) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-15" (TID:0x5fa9428, sys_thread_t:0x22064b88, state:CW, native ID:0x8ec) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-14" (TID:0x5fa9478, sys_thread_t:0x22064aa0, state:CW, native ID:0x24c) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-13" (TID:0x5fa8f68, sys_thread_t:0x22064930, state:CW, native ID:0x410) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-12" (TID:0x5fa8fb8, sys_thread_t:0x22064848, state:CW, native ID:0x3f0) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-11" (TID:0x5fa86b8, sys_thread_t:0x220607f0, state:CW, native ID:0xb28) prio=5
     at java.lang.Object.wait(Native Method)
     at org.apache.tomcat.util.ThreadPool$MonitorRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-10" (TID:0x5fa85f0, sys_thread_t:0x22061618, state:R, native ID:0x6fc) prio=5
     at java.net.PlainSocketImpl.socketAccept(Native Method)
     at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:414)
     at java.net.ServerSocket.implAccept(ServerSocket.java:242)
     at java.net.ServerSocket.accept(ServerSocket.java:224)
     at org.apache.tomcat.service.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:286)
     at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java, Compiled Code)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-9" (TID:0x5fa8648, sys_thread_t:0x22061530, state:CW, native ID:0x484) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-8" (TID:0x5fa83f0, sys_thread_t:0x220613c0, state:CW, native ID:0x8f0) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-7" (TID:0x5fa8440, sys_thread_t:0x22061250, state:CW, native ID:0x94c) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-6" (TID:0x5fa8490, sys_thread_t:0x220610e0, state:CW, native ID:0x994) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-5" (TID:0x5fa84e0, sys_thread_t:0x2205a2a8, state:CW, native ID:0x530) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-4" (TID:0x5fa8120, sys_thread_t:0x2205a138, state:CW, native ID:0x730) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-3" (TID:0x5fa8170, sys_thread_t:0x2205a050, state:CW, native ID:0x688) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-2" (TID:0x5fa81c0, sys_thread_t:0x2205a560, state:CW, native ID:0x3c0) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-1" (TID:0x5fa8218, sys_thread_t:0x22053520, state:CW, native ID:0x8fc) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"StandardManager" (TID:0x5fa1158, sys_thread_t:0x220596a0, state:CW, native ID:0x724) prio=5
     at java.lang.Thread.sleep(Native Method)
     at org.apache.tomcat.session.StandardManager.threadSleep(StandardManager.java, Compiled Code)
     at org.apache.tomcat.session.StandardManager.run(StandardManager.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"StandardManager" (TID:0x5f9d178, sys_thread_t:0x22031d18, state:CW, native ID:0xaa0) prio=5
     at java.lang.Thread.sleep(Native Method)
     at org.apache.tomcat.session.StandardManager.threadSleep(StandardManager.java, Compiled Code)
     at org.apache.tomcat.session.StandardManager.run(StandardManager.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"StandardManager" (TID:0x5f872f8, sys_thread_t:0x21c8b718, state:CW, native ID:0x880) prio=5
     at java.lang.Thread.sleep(Native Method)
     at org.apache.tomcat.session.StandardManager.threadSleep(StandardManager.java, Compiled Code)
     at org.apache.tomcat.session.StandardManager.run(StandardManager.java, Compiled Code)
     at java.lang.Thread.run(Thread.java:479)
"Thread-0" (TID:0x5f4e670, sys_thread_t:0x21b0eac0, state:CW, native ID:0x8bc) prio=5
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java, Compiled Code)
     at org.apache.tomcat.util.Queue.pull(Queue.java, Compiled Code)
     at org.apache.tomcat.logging.LogDaemon$1.run(TomcatLogger.java, Compiled Code)
     at org.apache.tomcat.logging.LogDaemon.run(TomcatLogger.java, Compiled Code)
"SymcJIT-LazyCompilation-1" (TID:0x5f2e4f8, sys_thread_t:0x20e977d8, state:CW, native ID:0x458) prio=1
     at SymantecJITCompilationThread.DoCompileMethod(Native Method)
     at SymantecJITCompilationThread.run(JITcompilationthread.java, Compiled Code)
"SymcJIT-LazyCompilation-0" (TID:0x5f2e540, sys_thread_t:0x20e9b6d0, state:CW, native ID:0x9bc) prio=1
     at SymantecJITCompilationThread.DoCompileMethod(Native Method)
     at SymantecJITCompilationThread.run(JITcompilationthread.java, Compiled Code)
"SymcJIT-LazyCompilation-PA" (TID:0x5f2e508, sys_thread_t:0x20e9b560, state:CW, native ID:0x820) prio=10
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at SymantecJITCompilationThread.run(JITcompilationthread.java, Compiled Code)
"Finalizer" (TID:0x5f29320, sys_thread_t:0x20dddec0, state:CW, native ID:0x4e8) prio=8
     at java.lang.Object.wait(Native Method)
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java, Compiled Code)
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java, Compiled Code)
     at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:174)
"Reference Handler" (TID:0x5f293b0, sys_thread_t:0x20ddc7d0, state:CW, native ID:0x55c) prio=10
     at java.lang.Object.wait(Native Method)
     at java.lang.Object.wait(Object.java:424)
     at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:114)
"Signal dispatcher" (TID:0x5f293e0, sys_thread_t:0x20dda218, state:R, native ID:0xa1c) prio=5
Monitor Cache Dump:
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA8178/6FF4140: <unowned>
     Waiting to be notified:
     "Thread-3" (0x2205a050)
java.net.PlainSocketImpl@5FA7DC0/6FF18C8: owner "Thread-10" (0x22061618) 1 entry
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA8128/6FF4248: <unowned>
     Waiting to be notified:
     "Thread-4" (0x2205a138)
SymantecJITCompilationThread@5F2E540/6C1F6A0: <unowned>
     Waiting to be notified:
     "SymcJIT-LazyCompilation-PA" (0x20e9b560)
org.apache.tomcat.util.ThreadPool$MonitorRunnable@5FAA1D8/6FFF340: <unowned>
     Waiting to be notified:
     "Thread-33" (0x22092f98)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA95D8/6FFADA8: <unowned>
     Waiting to be notified:
     "Thread-20" (0x22055448)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA81C8/6FF32F8: <unowned>
     Waiting to be notified:
     "Thread-2" (0x2205a560)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA9598/6FFAC90: <unowned>
     Waiting to be notified:
     "Thread-19" (0x22055360)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA8448/6FF4978: <unowned>
     Waiting to be notified:
     "Thread-7" (0x22061250)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA9C50/6FFBAF8: <unowned>
     Waiting to be notified:
     "Thread-24" (0x2207f8f0)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA9430/6FFA840: <unowned>
     Waiting to be notified:
     "Thread-15" (0x22064b88)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA9C00/6FFC850: <unowned>
     Waiting to be notified:
     "Thread-25" (0x2207fb78)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA84E8/6FF4350: <unowned>
     Waiting to be notified:
     "Thread-5" (0x2205a2a8)
org.apache.tomcat.util.ThreadPool$MonitorRunnable@5FA94A8/6FFAFB8: <unowned>
     Waiting to be notified:
     "Thread-22" (0x220556a0)
org.apache.tomcat.util.Queue@5F4E6C0/6D4B798: <unowned>
     Waiting to be notified:
     "Thread-0" (0x21b0eac0)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA8498/6FF4458: <unowned>
     Waiting to be notified:
     "Thread-6" (0x220610e0)
java.net.PlainSocketImpl@5FA9768/6FFB970: owner "Thread-28" (0x22080518) 1 entry
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA8F70/6FFA630: <unowned>
     Waiting to be notified:
     "Thread-13" (0x22064930)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA9B60/6FFCA60: <unowned>
     Waiting to be notified:
     "Thread-27" (0x2207ff00)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA9740/6FFB9F0: <unowned>
     Waiting to be notified:
     "Thread-23" (0x22055c18)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA9340/6FFAB88: <unowned>
     Waiting to be notified:
     "Thread-18" (0x220551f0)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA8F20/6FFA738: <unowned>
     Waiting to be notified:
     "Thread-14" (0x22064aa0)
java.lang.ref.ReferenceQueue$Lock@5F29338/6BF89C0: <unowned>
     Waiting to be notified:
     "Finalizer" (0x20dddec0)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA83F8/6FF4A80: <unowned>
     Waiting to be notified:
     "Thread-8" (0x220613c0)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA93E0/6FFA948: <unowned>
     Waiting to be notified:
     "Thread-16" (0x22064cf8)
java.net.PlainSocketImpl@5FA8FE8/6FF9860: owner "Thread-21" (0x220555b8) 1 entry
java.lang.ref.Reference$Lock@5F293C0/6BF84B8: <unowned>
     Waiting to be notified:
     "Reference Handler" (0x20ddc7d0)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA8FC0/6FF98E0: <unowned>
     Waiting to be notified:
     "Thread-12" (0x22064848)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA9BB0/6FFC958: <unowned>
     Waiting to be notified:
     "Thread-26" (0x2207fd90)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA9390/6FFAA80: <unowned>
     Waiting to be notified:
     "Thread-17" (0x22055080)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA8650/6FF4B88: <unowned>
     Waiting to be notified:
     "Thread-9" (0x22061530)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA9E50/6FFF128: <unowned>
     Waiting to be notified:
     "Thread-31" (0x22080228)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA8220/6FF31A8: <unowned>
     Waiting to be notified:
     "Thread-1" (0x22053520)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA9EF0/6FFEF18: <unowned>
     Waiting to be notified:
     "Thread-29" (0x2207e758)
org.apache.tomcat.util.ThreadPool$MonitorRunnable@5FA86C0/6FF5858: <unowned>
     Waiting to be notified:
     "Thread-11" (0x220607f0)
org.apache.tomcat.util.ThreadPool$ControlRunnable@5FA9EA0/6FFF020: <unowned>
     Waiting to be notified:
     "Thread-30" (0x22080140)
Registered Monitor Dump:
SymcJIT Method Monitor: <unowned>
SymcJIT Method Monitor: <unowned>
SymcJIT Method Monitor: <unowned>
SymcJIT Lazy Queue Lock: <unowned>
     Waiting to be notified:
     "SymcJIT-LazyCompilation-0" (0x20e9b6d0)
     "SymcJIT-LazyCompilation-1" (0x20e977d8)
SymcJIT Method Monitor: <unowned>
SymcJIT Method List Monitor: <unowned>
SymcJIT Lock: <unowned>
utf8 hash table: <unowned>
JNI pinning lock: <unowned>
JNI global reference lock: <unowned>
BinClass lock: <unowned>
Class linking lock: <unowned>
System class loader lock: <unowned>
Code rewrite lock: <unowned>
Heap lock: <unowned>
Monitor cache lock: owner "Signal dispatcher" (0x20dda218) 1 entry
Thread queue lock: owner "Signal dispatcher" (0x20dda218) 1 entry
     Waiting to be notified:
     "Thread-34" (0x2f4158)
Monitor registry: owner "Signal dispatcher" (0x20dda218) 1 entry
</pre>
Regards,
Prashant

No. we are getting the thread dumps only on the production server, and it being running on production, we cannot try it out with newer versions. However, we have so far been unable to simulate the thread dumps on our machines using the same version.

Similar Messages

Redirecting JVM thread dump to a file

The full thread dump of the JVM can be obtained by pressing ctrl-break in windows on the prompt from which the JVM is run and on solaris by executing the command "kill -QUIT pid" where pid is the process id of the JVM.
The thread dump will be printed on the console by default. But the requirement is to redirect this to a file. The following code redirects the dump to a file "Dump.txt".
System.out.close();
System.setOut(new PrintStream(new FileOutputStream("Dump.txt")));
Here we need to close the standard output stream "System.out" prior to redirecting it to a file. This is because if System.setOut is done without closing it the JVM still gives the thread dump on the initial standard output i.e., console. But if console is closed once we cannot get it back for the rest of the running time of the JVM.
IS THERE ANY SOLUTION TO THIS PROBLEM OF REDIRECTING DUMP TO A FILE, WITHOUT CLOSING THE STANDARD OUTPUT? The application should be able to get the standard output(console) back whenever it's required.

Hi,
I think that you can use a API for logs, as Log4J from Apache or Logger in java.util.logging... both are very simple...
good luck.
Mad.

Getting a thread dump

Is there a way from within a java program to get a thread dump of the jvm? I want to write some code that watched for a certain condition, then immediatly halts the jvm and dumps all the thread state.
Thanks for your ideas...

Thanks, but... those methods are useful for getting a status of the current thread, or of other threads in your thread group, but that is not I'm after.
What I need is similar to the effect of sending a SIGQUIT signal to the JVM, causing it to stop and dump all the thread state. I want to trigger that from code running in the JVM.
Basically I am trying to track down a bug in a complex server application, where on a dual processor box (only!), the current time zone gets reset to GMT at some point. It happens at some non-deterministic point in the application's lifetime. The app is multithreaded. I was going to just write a watchdog thread that continually monitored the timezone, then when the timezone changed the watchdog would dump all thread states. After doing this a few times I was hoping to see a pattern in where the various threads were executing. Needless to say, I have examined all the code, and nothing is setting the timezone explicitly.

Full thread dump Classic VM

When I'm trying to connect with a few clients to the IAS Server the Apache-server crashes. In the log file following error is shown:
full thread dump classic VM (JDK-1.2.2_005, native threads)
"SocketTimeout" at java.lang.thread.sleep at HTTP Client.SocketTimeOut.run
Does anyone know how I can fix this?
Nathalie

Did you ever figure this out?

Can't Redirect -classic thread dump/stack trace

Hi,
But how can you redirect the output so you can view it easily, instead of the info just scrolling by into oblivion? I'm using Win98 and JDK1.3.1_02, and w/ the default hotspot jvm, from the console, I could redirect the stack trace/thread dump from standard out (w/c it went into) into a file.
But w/ the -classic option (from the SDK java version, not the JRE), the stack trace/thread dump does NOT seem to sent to standard out, because I can redirect standard out, but the trace/dump is STILL going to the screen. I have redirected standard err (from w/in my java program) as well, but still no dice!
Help! TIA,
Reggie

Thanks for your reply guys! I also tried redirecting std err from inside my java app. My System.err outputs WERE redirected, but NOT the thread dump - that STILL went to the screen.
Then I tried the "java 2>error.txt myclass" but win98 thought 2 was the name of my class and threw a NoClassDefFoundError ;-).
Any more ideas? regards,
Reggie

Classic JVM hangs when running Tomcat as Windows Service

Hi!
I am running a Tomcat 3.2.4 application, written with Java 1.3.1_01.
To run it as a Windows Service (W2000), I am using a slightly altered version of JavaService, which works fine so far: I can use both the "hotspot" and the "server" JVM's (by selecting the jvm.dll from the respective subfolder of the JDK/jre/bin folder).
However, when I try to run the same application with the "classic" JVM, the service starts, inside of it Tomcat starts, the first output appears (to the stdout logfile) and after some time Tomcat simply hangs - it doesn't respond to anything anymore, 0% CPU, no output to logfiles anymore, doesn't even respond to normal Tomcat shutdown (e.g. when stopping the service, Windows waits the standard timeout then just kills it).
Using the classic JVM in a console (e.g. not through JavaService and the classic/jvm.dll) works fine! No problems!
Anyone here who can offer any help on this?
Any hints why Tomcat may behave correctly in 5 out of six possible configurations (hotspot-server/client as service or console or classic as console) but hanging with 1 configuration (classic as service)?
Also, on my W2000 box where this happens, the moment Tomcat hangs, I hear a Windows warning sound being played (the standard warning gong), like it happens when an info dialog pops up - only there is no dialog or whatever and the same moment Tomcat's CPU usage drops to 0% (although the app is still in startup and should do some more work for a few seconds).
This also doesn't always happen at the same moment during startup, but each time at a different moment, e.g. I can not pin it down to something that is done during startup, it just happens a short while (sometimes earlier, sometimes later) after startup...
Of course, I could simply say "forget classic, it's being phased out anyway", only: The SAME thing happens with IBM's Java 1.3 VM too (except for the gong sound, which seems to be Sun-JVM specific ;-)! And I would very much like my app to be able to run on IBM's VM (usually I'm using Sun's VMs everywhere, but we have a few stray W2000 boxes with SP2 where Sun's 1.3.1_0x VMs crash with our application [not hang like described above, but really crash, even when run as a console]) and on those boxes the IBM JVM in a console works fine - now I only have to get it working as a service too (and while researching why it hangs I saw that Sun's classic JVM hangs too, so I figured, I first find out why that happens, with the hope that the fix is applicable to IBM's JVM too...).
Thanks already,
Johannes

re setting classpath when using JavaService
for Win2k, Tomcat 3.3.1a, JDK1.2
below is my script for creating/installing JavaService
(based on Alexandria web site version). However, if i
try to add .jar files to classpath (ie, CP environment
variable), the service does not work. It only works
when this single .jar file is there. How can .jar or
.zip files be added to classpath for this service?
I've not been working with Tomcar as a service, so can't help directly, but can offer some comments that might be of use (apologies if they aren't!).
There are Tomcat scripts for V3.1, V3.2 and V4 with the JavaService code from Alexandria SC. Looks like you need one for V3.3 as well?
In these others, there are fairly long lists of jar files in the classpath, so I would expect it to work correctly for the version you are using (unless there is a problem with the way that classloaders are involved, which is something that is known to get in the way for some app server-based programs).
I would expect the classpath to work if changed from what you have listed to something like the following:
set CP=%TOMCAT_HOME%\lib\tomcat.jar;%TOMCAT_HOME%\lib\jaxp.jar;%TOMCAT_HOME$\lib\other_library.jar
Is that what you have tried to do, and found problems?
Does this version of Tomcat bundle all of its resources into a single jar file (tomcat.jar), or is that a file you have created yourself?
Is the problem found when loading and starting Tomcat itself, or from within your server-based application?
Does it fail to load a 'standard' Tomcat library archive, or a jar file containing your own program code?
set CP=%TOMCAT_HOME%\lib\tomcat.jar
echo %CP%
JavaService.exe -install "Jakarta-Tomcat"
%java_home%\jre\bin\classic\jvm.dll
-Djava.class.path=%CP% -Dtomcat.home=%TOMCAT_HOME%
-Djava.security.policy=%TOMCAT_HOME%/conf/tomcat.policy
-Xms128m -Xmx128m -start
org.apache.tomcat.startup.Main -params start -stop
org.apache.tomcat.startup.Main -params stop -out
%TOMCAT_HOME%\logs\stdout.log -err
%TOMCAT_HOME%\logs\stderr.log
Regards,
John Rutter

Thread running in jvm or os

pls tell me thread running in jvm or operating system

pls tell me thread running in jvm or operating systemIIRC, unless you are using a very old JVM (e.g. pre 1.2) or are explicitly specifying green threads (which I believe was still possible even in 1.2?) then all threading using native threads. As mentioned above, the mapping between Java thread objects and the native threads is is highly dependent on the OS (especially when it comes to thread priority).
This document goes into much more detail: http://java.sun.com/docs/hotspot/threads/threads.html
- N

Need help interpreting jvm thread dump (linux)

hi,
i'm using jre1.4.2 and running AS3 Linux kernel version 2.4.
i grep'ed for my java process id, and did a kill -3 on it to get the thread dump:
ps -ef |grep Eatroot 3936 3845 68 16:12 pts/2 00:00:05 java EatCpu
root 3948 30293 0 16:12 pts/3 00:00:00 grep Eat
kill -3 3936
thread dump:
java EatCpuFull thread dump Java HotSpot(TM) Client VM (1.4.2_05-b04 mixed mode):
"Thread-0" prio=1 tid=0x081126b8 nid=0xf60 runnable [aa7e0000..aa7e087c]
at EatCpu.run(EatCpu.java:31)
"Signal Dispatcher" daemon prio=1 tid=0x080a6a58 nid=0xf60 waiting on condition [0..0]
"Finalizer" daemon prio=1 tid=0x08092ee8 nid=0xf60 in Object.wait() [aad4d000..aad4d87c]
at java.lang.Object.wait(Native Method)
- waiting on <0xaaed0490> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
- locked <0xaaed0490> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=1 tid=0x08091498 nid=0xf60 in Object.wait() [aadce000..aadce87c]
at java.lang.Object.wait(Native Method)
- waiting on <0xaaed0380> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:429)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:115)
- locked <0xaaed0380> (a java.lang.ref.Reference$Lock)
"main" prio=1 tid=0x0805bae0 nid=0xf60 runnable [bfffc000..bfffcc98]
at EatCpu.main(EatCpu.java:22)
"VM Thread" prio=1 tid=0x08090238 nid=0xf60 runnable
"VM Periodic Task Thread" prio=1 tid=0x080a9248 nid=0xf60 waiting on condition
"Suspend Checker Thread" prio=1 tid=0x080a6020 nid=0xf60 runnable
i read that "nid" in the thread dump is suppose to correspond to PID. when i give the -m option for the "ps" command (for all threads), i see:
ps -efm |grep Eatroot 3936 3845 43 16:12 pts/2 00:00:04 java EatCpu
root 3937 3936 0 16:12 pts/2 00:00:00 java EatCpu
root 3938 3936 0 16:12 pts/2 00:00:00 java EatCpu
root 3939 3936 0 16:12 pts/2 00:00:00 java EatCpu
root 3940 3936 0 16:12 pts/2 00:00:00 java EatCpu
root 3941 3936 0 16:12 pts/2 00:00:00 java EatCpu
root 3942 3936 0 16:12 pts/2 00:00:00 java EatCpu
root 3943 3936 0 16:12 pts/2 00:00:00 java EatCpu
root 3944 3936 30 16:12 pts/2 00:00:03 java EatCpu
root 3950 30293 0 16:12 pts/3 00:00:00 grep Eat
>
but nid for all threads in the thead dump is the PID of my main process, 3936 (0xf60). is there a way to correlate the PIDs produced by "ps -efm" to the threads in the thread dump?
thanks!
-annie

i upgraded to 1.5 version of java, and could see distinct "nids" in the thread dump after that..

JVM Thread Dump

Hello, I am using JES 2003Q4. I would like to be able to obtain a jvm thread dump on the portal server. However when I issue a kill -3 to any of the webservd processes, the web server simply shuts down. No thread dump is observed in the error log. I am not using the -Xrs option in my server.xml file. Is there any way to force a thread dump? Doing so without stopping the web server would be preferable but not absolutely necessary.
Thanks!

Well you could try debug and verbose. I've got a feeling that on windows you only see the parent process in the thread dump. Is it possible for you to try this on a 'nix platform? You might get more information.

Thread Dump issue with LD_ASSUME_KERNEL=2.4.1

Hi ,
When I take Thread Dump using 'jstack <PID>' in JDK 1.5 it givss me "sun.jvm.hotspot.debugger.DebuggerException" in the dump nothing more
I set LD_ASSUME_KERNEL=2.4.1 in my server to avaoid some other issue ( JVM crash some times)
Surprisingly, I can not stop my server ( my java process ) after that using our Shutdow scripts , Ctrl C or even "kill -9 <PID>",
I have to restart the machine or manually release uncleaned resources that my server occupied and restart the server
This happens Redhar 9 as well as in Linux ES.
Anybody faced similar problem?
Any help or information regarding this is highly apprecialted
Vasu
Thread Dump Output:
Caused by: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet0(Native Meth
od)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$800(LinuxDebuggerLocal.java:34)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1GetThreadIntegerRegisterSetTask.doit(Li
nuxDebuggerLocal.java:431)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(Linux
DebuggerLocal.java:109)
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_re
gs failed for a lwp
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(L
inuxDebuggerLocal.java:134)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebugge
rLocal.java:437)
at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:48)
at sun.jvm.hotspot.runtime.linux_x86.LinuxX86JavaThreadPDAccess.getCurrentFrameGuess(LinuxX86
JavaThreadPDAccess.java:75)
at sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:252)
at sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:211)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:42)
at sun.jvm.hotspot.tools.JStack.run(JStack.java:41)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:204)
at sun.jvm.hotspot.tools.JStack.main(JStack.java:58)
Caused by: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet0(Native Meth
od)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$800(LinuxDebuggerLocal.java:34)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1GetThreadIntegerRegisterSetTask.doit(Li
nuxDebuggerLocal.java:431)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(Linux
DebuggerLocal.java:109)
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_re
gs failed for a lwp
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(L
inuxDebuggerLocal.java:134)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebugge
rLocal.java:437)

@brain0
I've downloaded the glic-2.3.6 sources from gnu, so I could build it from those. I'm however reluctant to do this because I really don't want to break my install.
I do agree with you on the NPTL statement, but pvs relies on allegro, which relies on LinuxThreads. Allegro is not being ported to new versions of glibc, so that approach is unfortunately not viable.
@iphitus
I wasn't very specific - it's allegro as in a lisp environment.
I think I'll try and install an old version of arch on wmware instead. Is there anywhere you can check out glibc version numbering on old arch install isos (ie. do I need arch-0.[1-9].iso)? And anywhere you can download the old isos (tried filewatcher, but a lot of the older sites seem broken)?
Thanks for the replies,
Mads
PS. I noticed that you recommended slackware for old kernels in another thread. I'm however in a bit different situation as I need old versions of glibc. Furthermore I would prefer sticking to arch, but was wondering whether there were any specific reasons for not doing that.

WL 7.0 thread dump question

Hi,
I am using weblogic 7.0 windows 2000. I have seen unique behaviour with this,
if the server is not accessed for prolonged time, say overnight and in the morning
if I want to take thread dump(by hitting Ctrl+break) it will not work. I need
to restart server to get thread dump, any idea about this?
Yogesh

Ctrl+break is a JVM interrupt command, not WLS.
Is the server accessible? I mean does it respond for PING
BTW, what JDk you are using?
Kumar
Yogesh wrote:
Hi,
I am using weblogic 7.0 windows 2000. I have seen unique behaviour with this,
if the server is not accessed for prolonged time, say overnight and in the morning
if I want to take thread dump(by hitting Ctrl+break) it will not work. I need
to restart server to get thread dump, any idea about this?
Yogesh

SIGQUIT ignored / no thread dump in 1.5/5.0 ?

Trying out 1.5 on a dual-xeon, Linux 2.4.27 machine. - 'java -version' returns:
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)
Java process seems to ignore 'kill -SIGQUIT' -- nothing to stderr/stdout, nothing to working directory. A thread dump would be really handy. No special options were used to launch JVM.
Any ideas?

I'm having a problem with the same symptom: SIGQUIT is ignored. So I ran jstack and got this:
Error occurred during stack walking:
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(LinuxDebuggerLocal.java:134)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebuggerLocal.java:437)
at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:48)
at sun.jvm.hotspot.runtime.linux_x86.LinuxX86JavaThreadPDAccess.getCurrentFrameGuess(LinuxX86JavaThreadPDAccess.java:75)
at sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:252)
at sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:211)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:42)
at sun.jvm.hotspot.tools.JStack.run(JStack.java:41)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:204)
at sun.jvm.hotspot.tools.JStack.main(JStack.java:58)
Caused by: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet0(Native Method)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$800(LinuxDebuggerLocal.java:34)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1GetThreadIntegerRegisterSetTask.doit(LinuxDebuggerLocal.java:431)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(LinuxDebuggerLocal.java:109)
Any ideas/suggestions? Anyone seen this before?

100% CPU load but no clue in thread dump, EP. Win a bottle of champagne...

Hi,
We are suddenly facing 100% CPU load in our EP cluster (5 x 8-way Xeon multiprocessor machines). We have a serious performance problem that is burning a lot of our time and causes a lot of stress for over 3 weeks now.
We have taken tens of thread dumps from Application Nodes.
- In none of the thread dumps we see the Finalizer thread
running.
- From the garbage collector log we see that full garbage
collection runs occur very rarily (once an hour).
- We use the compacting garbage collector.
- In a lot of thread dumps we do not even see our own portal code in the stack traces of the threads!
- In Windows Task Manager we see the jlaunch.exe processes
consume all available CPU time.
- Portal users see a blank portal page when the CPU load hits 100%. When the load goes down again, things return to normal.
- There are no errors logged in any of the log files of the portal. We checked all of them. We expected a log full of errors somewhere but nothing even remotely interesting was found. Windows Event Viewer shows nothing either.
- The amount of sockets in CLOSE_WAIT status is < 10 on every machine in the cluster.
This forces me to conclude that something in the jlaunch.exe executable consumes the CPU time. This raises the following 3 questions:
- What does the mystifying jlaunch.exe do besides executing java.exe ?
- Why is the Java virtual machine launched by a custom executable like jlaunch (What is it that cannot be program med in Java) ? Can it be GZip compression ?
- If the problem is not caused by jlaunch.exe, then it must be caused by the JVM. What activity, invisible in thread dumps, is performed by the JVM that can cause the high CPU load ?
Our development- and support teams are desperate. All suggestions are welcome. The person that comes up with
the solution to our problem gets a nice bottle of champagne.
Regards,
Chris Twigt

Hi,
- What does the mystifying jlaunch.exe do besides executing java.exe ?
This is so that the startupframework can connect more easily and take control of the JVM in some situations
- Why is the Java virtual machine launched by a custom executable like jlaunch (What is it that cannot be program med in Java) ?
I assume when SAP release their JVM (in the next major release), that will be called directly.
- If the problem is not caused by jlaunch.exe, then it must be caused by the JVM. What activity, invisible in thread dumps, is performed by the JVM that can cause the high CPU load ?
Loads of thing, but there should be clues in the thread dumps. (the reason why your code is not in those thread dumps is that your code is only active during the processing of a particular request, unless you have a service, afterwards there are no trace of it as the thread which does the processing goes back to sleep)
I've experienced a similar situation with a an 6.40 portal, and it was then caused by the following:
1. User A comes logs in and sees that some cache timeout has occured , therefore it issues a SQL query which does a full table scan on a table of approx. 1 GB (on of the UME tables)
2. User B comes in just afterwards and also sees that the cache timeout has occured, and issues the same SQL query as User A
3. User C .... and so on untill the query from User A eventually finishes
So
1. Check database. Any big queries running ?
2. Check file activity, are there a lot of writing ?
3. Check network activity, especially to the state controller which is the weakest link
4. What about portal logs ? Any activity during the hang ?
Also, please provide one of the thread dumps for further analysis..
cheers
Dagfinn

Generate thread dump without sending ctrl-break on Win32

I have a server application running as a service on Win2k (we use Service+ to do this). The output of the console is piped to a text file which we can monitor. But, I can't figure out how to generate a thread dump while running in this configuration. Does anyone know if Service+ can be configured to do this, or if it can be achieved programmatically (how does Sun spit out the thread info when it gets the request).
Thanks,
Larry

If you are running a java application on a Windows server. You can press Ctrl-Break, and a thread dump will be displayed in the console. This thread dump is a list of all the threads running in the JVM, and the line of code they are each executing.
We'd like to be able to generate this thread dump some other way than pressing Ctrl-Break, because we don't have a console, our application is running as a service using Service .
Thanks for the reply,
Larry0AThanks for the reply,
Larry

Thread dump: any way to do it programmaticly?

Sun introduced a new deadlock detection utility with 1.4.1: if you type invoke with Ctrl Break (windoze) / Ctrl + (unix) on the shell command line which launched your jvm, you will get a thread dump to std out
http://java.sun.com/j2se/1.4.2/docs/guide/vm/
But I am faced with a situation where I would like to programmaticly dump the thread state, that is, from my java code itself I would like to issue a command to thread dump to some OutputStream. (In my case, I would like to do this if my program detected some problem that will cause it to abort, and I would like to do the thread dump first so that I can inspect it afterwards and see what the thread state was at the time.)
Does anyone know how to do this?
Is there a way of overriding System.in, say, so that you can send the chars equivalent to Ctrl Break to the jvm?

You can look at the new APIs in JDK 5.0: getStackTrace
and Thread.getAllStackTraces.
-Alexis

Thread dump running Classic JVM(jdk 1.2.2)

Similar Messages

Maybe you are looking for