The Thread Dump Plugin has been removed from Confluence as of 5.8. The Support Tools Plugin now triggers multiple thread dumps that can be viewed in TDA and Samurai as part of creating a Support Zip.

I'm currently speaking with Product Management about unbundling it:

Confluence Thread Dump Plugin:
https://marketplace.atlassian.com/plugins/com.atlassian.confluence.plugin.threaddump/versions

Here's the source:
https://bitbucket.org/atlassian/confluence-threaddump-plugin

Originally built for Confluence 3.0. There hasn't been a functionality change since August 2013.

It's made up of only 4 classes, and there are no analytics events being fired by it. It has 3 uses - you can schedule a thread dump, generate one manually, and it's added to the Support Zip when one is created. In all cases it's a single thread dump which is useless, and can't be parsed by TDA etc, which is again totally useless.

I disabled it and the Support Zip is still created with no problem - the Support Tools Plugin hasn't been including thread dumps generated by this plugin for a while.

So, as far as I can see there will be no system impact if we remove it.

The Support Tools Plugin now includes thread dumps that can be loaded into TDA etc. Reopening this ticket to deprecate the Confluence Thread Dump Plugin in 5.8 and remove it in 5.9.

This issue was fixed in Support Tools Plugin version 3.5.26, which is compatible with Confluence 4.3 and above. It can be updated through Admin > Manage Add-ons.

Support Tools Plugin 3.5.26 will be bundled with Confluence 5.8.

FYI: I tried to address this problem in my last ShipIt: https://shipit.atlassian.net/browse/SHPXXVII-121

If you will not be "fixing" this, could you please improve the documentation on how to analyse it manually? This gives some insight - https://confluence.atlassian.com/x/zgC6C - except that my thread dump generated by Confluence doesn't look like this!

Thanks for your comment, Matt.
I actually missed that point about "browsing" through the dump to check for code sections. It seems I have a particular use cases in mind (finding long running threads). And I can do that with generating an external thread dump. So it is not a really important issue...

Thanks for the feedback, Michael. We'd definitely like to improve the thread dump output, but we don't have this work scheduled at the moment.

To answer your question, yes, the output is useful even without the locking information. It is useful to our support and development teams when debugging performance issues. We often just look through the thread dump to see what the threads are doing; there's no need for a tool to draw a conclusion if the majority of threads are obviously all stuck in the same section of code.

I highly urge you to resolve this issue. Without a proper way to analyse the generated thread dump, this plugin is simply useless: I don't understand the idea behind the plugin if the generated dump cannot be read by an analysis tool (IBMs JCA also fails to read it...).

What do other people do with the dump? Am I missing anything here?

In my tests ThreadInfo.toString()gives the same output as a native thread dump generated by SIGQUIT, with the important difference that it truncates stack traces to 10 levels or so. My approach was to rewrite write a similar method, without the stack trace truncation.