This discussion is archived
2 Replies Latest reply: Jan 3, 2013 8:52 AM by jtahlborn RSS

Taking thread dumps in production

andy dufresne Newbie
Currently Being Moderated
I am analyzing the differences between approaches for taking thread dumps in production environments. Below are the couple of them I am researching on

1. Defining a jmx bean which repeatedly triggers jstack through Runtime.exec() on clicking a declared bean operation.

2. Daemon thread executing "ManagementFactory.getThreadMXBean().dumpAllThreads(true, true)" repeatedly after a predefined interval.

Comparing the thread dump outputs between the two, I see the below disadvantages with approach 2

1. Thread dumps logged with approach 2 cannot be parsed by open source thread dump analyzers like TDA
2. The ouput does not include the native thread id which could be useful in analyzing high cpu issues (right?)
Any more?
I would appreciate to get suggestions/inputs on

1. Are there any disadvantages of executing jstack through Runtime.exec() in production code? any compatibility issues on various operating systems - windows, linux?

2. Any other approach to take thread dumps?

Thank you.
  • 1. Re: Taking thread dumps in production
    maheshguruswamy Journeyer
    Currently Being Moderated
    andy dufresne wrote:
    I am analyzing the differences between approaches for taking thread dumps in production environments. Below are the couple of them I am researching on

    1. Defining a jmx bean which repeatedly triggers jstack through Runtime.exec() on clicking a declared bean operation.

    2. Daemon thread executing "ManagementFactory.getThreadMXBean().dumpAllThreads(true, true)" repeatedly after a predefined interval.

    Comparing the thread dump outputs between the two, I see the below disadvantages with approach 2

    1. Thread dumps logged with approach 2 cannot be parsed by open source thread dump analyzers like TDA
    2. The ouput does not include the native thread id which could be useful in analyzing high cpu issues (right?)
    Any more?
    I would appreciate to get suggestions/inputs on

    1. Are there any disadvantages of executing jstack through Runtime.exec() in production code? any compatibility issues on various operating systems - windows, linux?

    2. Any other approach to take thread dumps?

    Thank you.
    I have always used kill -3 PID to get the thread dump. The docs for jstack (http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstack.html) have warnings around possible removal in the future and also compatibility issues.
  • 2. Re: Taking thread dumps in production
    jtahlborn Expert
    Currently Being Moderated
    andy dufresne wrote:
    I am analyzing the differences between approaches for taking thread dumps in production environments. Below are the couple of them I am researching on

    1. Defining a jmx bean which repeatedly triggers jstack through Runtime.exec() on clicking a declared bean operation.

    2. Daemon thread executing "ManagementFactory.getThreadMXBean().dumpAllThreads(true, true)" repeatedly after a predefined interval.

    Comparing the thread dump outputs between the two, I see the below disadvantages with approach 2

    1. Thread dumps logged with approach 2 cannot be parsed by open source thread dump analyzers like TDA
    why not? the format is up to you, i'm sure you could make it match (even if you didn't have all the info).
    2. The ouput does not include the native thread id which could be useful in analyzing high cpu issues (right?)
    this is a bit disappointing, however you can get a bit more information than ThreadInfo gives you. you can get the "cpu" and "user" time for each thread individually using the corresponding methods on the ThreadMXBean.
    Any more?
    I would appreciate to get suggestions/inputs on

    1. Are there any disadvantages of executing jstack through Runtime.exec() in production code? any compatibility issues on various operating systems - windows, linux?
    Another disadvantage of this approach is that jstack must be in the path (or you need to know the path to jstack), and you need to be able to determine the pid of the relevant process. also the complexities which come with invoking an external process.
    2. Any other approach to take thread dumps?
    we actually do a combination of 1 and 2, which is that we have a custom jmx bean with an operation which will use the ThreadMXBean info to dump thread stack info to our application log file. this works very well for us. we don't typically need to diagnose high cpu usage, but the opposite, blocked threads. this is usually very easy to determine with the info provided via ThreadInfo.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points