Many times you would want to tweak the performance of the ColdFusion server or want to debug the bottlenecks that make the server unresponsive.

To analyze this, ideally you would want to have Thead dumps and Server memory snapshot(Heap Space, Eden Space, Survivor Space, Old Gen, Perm Gen).

While you can use JDK tools like jstack to get the dumps, it is tedious to install it and schedule the thread dumps.

So, programmatically thread dumps and memory snapshots are are triggered and can be configured as a scheduler task and can be triggered on-demand as well.

Download the following zip file and move it to the server where you want to take thread dumps.

 

threaddump.zip

This zip file contains two files. One is threaddump.jar file.

Place this file under: C:\ColdFusion11\cfusion\wwwroot\WEB-INF\lib\ and restart the server for it to load.

And the other file is the cfm file takethreaddump.cfm where the call to ThreadDump class is made and the path where the dump content should be written.

By default it is dumped to the file #GetTempDirectory()#/threaddump<Day>-<Month>-<Year>.log

(Depending on the server location it translates similar to C:\ColdFusion11\cfusion\runtime\work\Catalina\localhost\tmp\threaddump12-8-2015.log)

You can change this to any other convenient path in the cfm file.

You can call this cfm on-demand at point of time or configure a new scheduled task to schedule it at some interval.

More number of Thread dumps are more helpful for problem analysis. So, it is better to take at some interval.

On every new day, dump is rotated automatically to a new file name.

 

3 Comments to “Taking Thread Dumps from ColdFusion Server Programmatically”

  1. Tyler Clendenin
    I assume the answer is no, but can this be used with JavaLoader?
  2. Charlie
    This is indeed interesting, Krishna. Thanks so much for sharing it. As Krishna indicates, sometimes there's real value in doing thread dumps, especially in their value to show you the exact line of code (if any) that a currently running request is executing.

    FWIW, folks interested in thread dumps may also want to know that if you setup the "alerts" feature in either the CF Enterprise Server Monitor, or in FusionReactor or SeeFusion, then those tools will all generate a thread dump and email it to you.

    They also each have an option to create a thread dump from within the interface of the tool. (Just like Krishna points out that JDK tools can create them on-demand also.)

    Better still, they all have an option to ONLY get a stack trace for a particular request (whereas a thread dump is a list of ALL stack traces for ALL threads, whether they are running CF requests or not.) That can be especially valuable.

    Wading through thread dumps can be pretty challenging. You need to be able to not only understand what you see (in each stack trace) but it is all the more challenging because you really can't tell from a thread dump alone what request was running what thread (and for how long, for who, and so on). That's there the other tools can have an advantage.

    Still, there's certainly value in this code/tool of Krishna's for a) those without the other tools, b) for creating them programmatically vs via alerts or on-demand, and c) to save them in a rotating filename/path as is done here. That's a nice touch. Thanks, Krishna.

    I'll note that I have a blog post on some of these other facets of getting and using thread dumps, especially from within such CF monitoring tools:

    http://www.carehart.org/blog/client/index.cfm/2009/6/24/easier_thread_dumps

    and I link there to a recorded hour-long presentation I'd done on the topic as well, which obviously gets into more depth. It's from 2010, but the info absolutely still applies.

    HTH.

    (One last comment: I find that some people confuse this with heap dumps. Those are something entirely different.)
  3. Tom Chiverton
    Sigh. Fonts are messed up in the article, compared to the surrounding articles.

Leave a Comment

Leave this field empty: