Additional abilities for thread dumps

[venkatasreekanth]

Problem: During issues, we need to take thread dumps. Most server products shop with their own JRE, and installation of JDK on servers in production is discouraged. Also finding the exact version and exact vendor is difficult. Jstack will not connect with a different version and even if you find the same version, it doesn't exactly work right, if you don't have the same vendor.

Describe the solution you'd like
Add ability to take thread dumps at intervals and write them to files with details like hostname and time as part of the file name.

Describe alternatives you've considered
use of jstack and scripting which isn't working very well. Seems like getting thread dumps is a lot easier with JMX for reason mentioned above.

Additional context
Let me know if you need additional information.

[thurka]

Jstack will not connect with a different version and even if you find the same version, it doesn't exactly work right, if you don't have the same vendor.

What you describe is not default behaviour of jstack. Nornally jstack uses Attach API and does not care about version or vendor (except IBM openj9). What you describe is behaviour of jstack -F, which should be used used only if java process completely hangs (on OS, not Java level). So can describe in more details what JDK/OS are you using? What does happen if you use plain jstack <pid>?

If you want to do periodic stack-traces via JMX when application behaves strangely, you can use CPU sampling with appropriate settings - samples can be several seconds apart. Sampling can be saved to file or as application snapshot and used for off-line analysis.

You can also use <visualvm_dir>/platform/modules/org-netbeans-modules-sampler.jar to create CPU sampling snapshot without visualvm and without GUI. More details are here.