1 Reply Latest reply: Jan 3, 2012 11:06 PM by 896552 RSS

    Different formats for thread dumps

    869397
      I have noticed that the format of a thread dump taken to a WLS 10.3 server, differs depending on the way it is taken:

      If I take the dump through the console or using WLST I get an output with this format:
      =======================================================================
      "Main Thread" waiting for lock weblogic.t3.srvr.T3Srvr@504ce6e WAITING
      java.lang.Object.wait(Native Method)
      java.lang.Object.wait(Object.java:485)
      weblogic.t3.srvr.T3Srvr.waitForDeath(T3Srvr.java:811)
      weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:459)
      weblogic.Server.main(Server.java:67)

      "(Signal Handler)" RUNNABLE
      null
      "(OC Main Thread)" RUNNABLE
      null
      "(Code Generation Thread 1)" RUNNABLE
      null
      "(Code Optimization Thread 1)" RUNNABLE
      null
      "(VM Periodic Task)" RUNNABLE
      null
      "(Attach Listener)" RUNNABLE
      Null
      ....
      =======================================================================

      If I take the dump sending a signal to the process, I get a much detailed format:

      ===== FULL THREAD DUMP =================================================
      Wed Dec 07 10:46:08 2011
      Oracle JRockit(R) R28.0.0-679-130297-1.6.0_17-20100312-2123-windows-ia32

      "Main Thread" id=1 idx=0x4 tid=6800 prio=5 alive, waiting, native_blocked
      -- Waiting for notification on: weblogic/t3/srvr/T3Srvr@0x28267370[fat lock]

      at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Metho
      d)
      at java/lang/Object.wait(J)V(Native Method)
      at java/lang/Object.wait(Object.java:485)
      at weblogic/t3/srvr/T3Srvr.waitForDeath(T3Srvr.java:811)
      ^-- Lock released while waiting: weblogic/t3/srvr/T3Srvr@0x28267370[fat lock
      ]
      at weblogic/t3/srvr/T3Srvr.run(T3Srvr.java:459)
      at weblogic/Server.main(Server.java:67)
      at jrockit/vm/RNI.c2java(IIIII)V(Native Method)
      -- end of trace

      "(Signal Handler)" id=2 idx=0x8 tid=7500 prio=5 alive, daemon

      "(OC Main Thread)" id=3 idx=0xc tid=8028 prio=5 alive, native_waiting, daemon

      "(GC Worker Thread 1)" id=? idx=0x10 tid=3564 prio=5 alive, daemon

      "(GC Worker Thread 2)" id=? idx=0x14 tid=5204 prio=5 alive, daemon

      "(GC Worker Thread 3)" id=? idx=0x18 tid=6848 prio=5 alive, daemon

      "(GC Worker Thread 4)" id=? idx=0x1c tid=7056 prio=5 alive, daemon
      "(Code Generation Thread 1)" id=4 idx=0x20 tid=1712 prio=5 alive, native_waiting
      , daemon

      "(Code Optimization Thread 1)" id=5 idx=0x24 tid=4416 prio=5 alive, native_waiti
      ng, daemon

      "(VM Periodic Task)" id=6 idx=0x28 tid=7060 prio=10 alive, native_blocked, daemo
      n

      "(Attach Listener)" id=7 idx=0x2c tid=7020 prio=5 alive, native_blocked, daemon
      .......
      =================================================================================

      I have the following questions:

      How can I get a detailed dump through the console or through WLST?

      Is there anything else apart from Samurai to analyze this dumps? Which format will Samurai like?
        • 1. Re: Different formats for thread dumps
          896552
          Hi,

          Below are the diff. types of mecahnisms for taking the Thread dump.

          1) If you are using Sun HotSpot JDK, use the below synatx to get the TD.
          ../jdk1.6.0_20/bin/jmap -J-d64 -heap 3455
          Note:: 3455 is your server PID.

          You can analyze this TD using Samurai.

          2) If you are using Oracle JRocket JDK, use the below synatx to get the TD.
          ../jrockit/bin/sparcv9/jrcmd 3455 print_threads
          Note:: 3455 is your server PID.

          You CAn't analyze generated dump using Samurai.

          3) You can go to below path on Console
          SErver --> Monitoring --> Threads --> Click on Dump Tread stacks
          Note: Here also if you are using Sun JDK, u can anayze using Samurai.

          With regards,
          Gopal