Caldarale, Charles R wrote:
>> From: Ofer Israeli [mailto:[email protected]]
>> Subject: RE: Tomcat with mod_jk becomes irresponsive after working
>> for awhile
>
>> I am in the situation where the server is giving 503s for all
>> incoming requests, so I did a capture now to see what the situation
>> is and as mentioned above I see Tomcat FINing the connections right
>> away before mod_jk sends any content
>
> You might want to take a thread dump of Tomcat and see just what is
> going on. If all the threads are busy (or stuck), you may well have
> an application problem causing the 503.
>
> - Chuck
>
Hi Chuck,
I've taken a thread dump and haven't found anything that looks suspicious.
What baffles me is that TaskManager shows that I have 580 threads in the Tomcat
process (which makes sense since I use 500 worker threads for requests), but
the thread dump only shows a small portion of these. Below is the dump, I'll
be happy if you can give me some insight on this.
2012-02-23 20:08:16
Full thread dump Java HotSpot(TM) Client VM (19.1-b02 mixed mode):
"Low Memory Detector" daemon prio=6 tid=0x16bc7400 nid=0x2b38 runnable
[0x00000000]
java.lang.Thread.State: RUNNABLE
"CompilerThread0" daemon prio=10 tid=0x16bbe400 nid=0x2828 waiting on condition
[0x00000000]
java.lang.Thread.State: RUNNABLE
"Attach Listener" daemon prio=10 tid=0x16bbcc00 nid=0xc4c runnable [0x00000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" daemon prio=10 tid=0x16bbb800 nid=0x1378 waiting on
condition [0x00000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" daemon prio=8 tid=0x16baac00 nid=0x2f4c in Object.wait()
[0x16d1f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x029f1158> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
- locked <0x029f1158> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" daemon prio=10 tid=0x16ba6000 nid=0x2c5c in Object.wait()
[0x16ccf000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x029f1058> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x029f1058> (a java.lang.ref.Reference$Lock)
"main" prio=6 tid=0x002a7c00 nid=0x2ecc runnable [0x0093f000]
java.lang.Thread.State: RUNNABLE
at sun.tools.attach.WindowsVirtualMachine.connectPipe(Native Method)
at
sun.tools.attach.WindowsVirtualMachine.execute(WindowsVirtualMachine.java:82)
at
sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:195)
at
sun.tools.attach.HotSpotVirtualMachine.remoteDataDump(HotSpotVirtualMachine.java:156)
at sun.tools.jstack.JStack.runThreadDump(JStack.java:159)
at sun.tools.jstack.JStack.main(JStack.java:94)
"VM Thread" prio=10 tid=0x16ba2400 nid=0x320 runnable
"VM Periodic Task Thread" prio=10 tid=0x16bcac00 nid=0x2cb4 waiting on
condition
JNI global references: 913
Heap
def new generation total 4928K, used 756K [0x029f0000, 0x02f40000,
0x07f40000)
eden space 4416K, 17% used [0x029f0000, 0x02aad0a0, 0x02e40000)
from space 512K, 0% used [0x02e40000, 0x02e40000, 0x02ec0000)
to space 512K, 0% used [0x02ec0000, 0x02ec0000, 0x02f40000)
tenured generation total 10944K, used 0K [0x07f40000, 0x089f0000, 0x129f0000)
the space 10944K, 0% used [0x07f40000, 0x07f40000, 0x07f40200, 0x089f0000)
compacting perm gen total 12288K, used 2379K [0x129f0000, 0x135f0000,
0x169f0000)
the space 12288K, 19% used [0x129f0000, 0x12c42d68, 0x12c42e00, 0x135f0000)
No shared spaces configured.
Thanks,
Ofer
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]