title: Taking thread dumps in production
body: <p>I am analyzing the differences between approaches for taking thread dumps. Below are the couple of them I am researching on</p>
  
  <ol>
  <li><p>Defining a jmx bean which triggers jstack through Runtime.exec() on clicking a declared bean operation.</p></li>
  <li><p>Daemon thread executing "ManagementFactory.getThreadMXBean().dumpAllThreads(true, true)" repeatedly after a predefined interval.</p></li>
  </ol>
  
  <p>Comparing the thread dump outputs between the two, I see the below disadvantages with approach 2</p>
  
  <ol>
  <li>Thread dumps logged with approach 2 cannot be parsed by open source thread dump analyzers like TDA</li>
  <li>The ouput does not include the native thread id which could be useful in analyzing high cpu issues (right?)</li>
  <li>Any more?</li>
  </ol>
  
  <p>I would appreciate to get suggestions/inputs on</p>
  
  <ol>
  <li><p>Are there any disadvantages of executing jstack through Runtime.exec() in production code? any compatibility issues on various operating systems - windows, linux?</p></li>
  <li><p>Any other approach to take thread dumps?</p></li>
  </ol>
  
  <p>Thank you.</p>
  
  <p><strong>Edit -</strong> </p>
  
  <p>A combined approach of 1 and 2 seems to be the way to go. We can have a dedicated thread running in background and printing the thread dumps in the log file in a format understood by the thread dump analyzers.
  If any extra information is need (like say probably the native thread id) which is logged only by the jstack output, we do it manually as required.</p>