[jboss-jira] [JBoss JIRA] Commented: (JBAS-5163) Add JDK 6 version of ServerInfo.listThreadDump() taking advantage of new management classes

[Galder Zamarreno (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBAS-5163?page=comments#action_12413692 ] 
            
Galder Zamarreno commented on JBAS-5163:
----------------------------------------

Re: Also, I'd like to see what would the extra jdk6 info be in the output (some example).

Yeah, definitely. In facf, not just that, I'm creating 2 deadlock examples (one with synchronised 
monitors and one with java.util.concurrent Lock class impl) so that you can also see how we can 
print out deadlocks both JDK5 and JDK6. We could do already print synchronized monitor deadlock 
with JDK5 already, but was not implemented.

One thing I'm changing for all thread dumps is the following:

Thread: JBossLifeThread : priority:5, demon:false, threadId:58, threadState:WAITING, lockName:java.l
ang.Object at 10cff6b

java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:474) 

Rather than "lockName: java.lang.Object at 10cff6b" in the title, it makes more sense to put it in the 
stack itself, in the same way that any standard thread dump output does, i.e:

Thread: JBossLifeThread : priority:5, demon:false, threadId:58, threadState:WAITING

- waiting on java.lang.Object at 10cff6b
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:474) 

The closer we are to real non JMX-console thread dumps, the easier for any of us to read them.

> Add JDK 6 version of ServerInfo.listThreadDump() taking advantage of new management classes
> -------------------------------------------------------------------------------------------
>
>                 Key: JBAS-5163
>                 URL: http://jira.jboss.com/jira/browse/JBAS-5163
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMX/Web Console
>    Affects Versions:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>             Fix For: JBossAS-5.0.1.CR1
>
>         Attachments: jmx-serverinfo.dump, kill-3.dump
>
>
> There're 4 ways to generate a thread dump. I have taken the output from the same run with 
> different methods:
> 1.- kill -3. Can be parsed by tools like https://tda.dev.java.net/ (simply, one of the most useful 
> tools I've found out there!). Example:
> "JBossLifeThread" prio=1 tid=0x0a690cc0 nid=0x1741 in Object.wait() [0x867f2000..0x867f30b0]
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x9247e200> (a java.lang.Object)
>         at java.lang.Object.wait(Object.java:474)
>         at org.jboss.system.server.ServerImpl$LifeThread.run(ServerImpl.java:940)
>         - locked <0x9247e200> (a java.lang.Object)	
> 2.- JMX via org.jboss.system.server.ServerInfo.listThreadDump(). Here's some output:
> Thread: JBossLifeThread : priority:5, demon:false, threadId:58, threadState:WAITING, lockName:java.l
> ang.Object at 10cff6b
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:474)
> org.jboss.system.server.ServerImpl$LifeThread.run(ServerImpl.java:940)	
> Lock name is different to lock monitor achieved via kill -3. Doesn't looks like it prints previously locked 
> monitors. Cannot be parsed by TDA tools because it's in JBoss specific format. 
> 3.- Thread.getAllStackTraces().
> Haven't tested the output from this. What would this print? Couldn't find an MBean that uses/parses 
> the output from this, but I suspect it's the same as method 2, specially since 
> http://jira.jboss.com/jira/browse/JBAS-1448 has already been fixed.
> 4.- JConsole Threads view:
> Code:
> Name: JBossLifeThread
> State: WAITING on java.lang.Object at 10cff6b
> Total blocked: 0  Total waited: 1
> Stack trace: 
> java.lang.Object.wait(Native Method)
> java.lang.Object.wait(Object.java:474)
> org.jboss.system.server.ServerImpl$LifeThread.run(ServerImpl.java:940)	
> Seems to print same info as JBoss' ServerInfo.
> Bottom line: we should try generating thread dumps that look like kill -3 
> output to make them more readable than in their current format and to 
> benefit from existing tools that can parse standard kill -3 format.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira