[Looking for Charlie's main web site?]

CF911: Easier thread dumps and stack traces in CF: how and why

Note: This blog post is from 2009. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
You may have heard the value of taking thread dumps or stack traces when trying to understand and resolve problems with CF. They can be valuable to see what's really running on your server at the time it may seem hung or slow to respond. The problem is that they can be challenging to obtain, so here's how to get them even more easily.

(If you're not familiar with the value of thread dumps or stack traces, read on. The resources I point to get help you to appreciate their usefulness.)

Update 1: I did a several minute youtube video on this topic.
Update 2: I did a presentation on this topic, posted here. After reading the below, you may want to view that with more details on stack tracing any of many ways.

Well, I was tooling around looking for some help on a topic when I happened upon an old entry from the awesome and ever-valuable blog of Steven Erat, formerly of Adobe and now of Webapper. The entry is An easier way to take ColdFusion thread dumps on Windows , and he actually points to entry in another classic blog by Brandon Purcell (formerly of Adobe and now with Universal Mind). Steven's entry also points to a classic Adobe technote on interpreting dumps and stack traces.

But both entries are from 2005, and since then there are still easier solutions for getting either a thread dump or stack trace, and I wanted to point them out (I'll also add a link to this entry in Steven's.)

For those on CF 6, 7, 8

First, for those running CF 6, 7, 8 (and other CFML engines, like Railo and Open BlueDragon), you can use either FusionReactor or SeeFusion, commercial monitoring tools, which each offer a simple single button to produce a thread dump (a stack trace for all threads running inside the JVM that underlies CF).

Better still, they also offer an option to get a stack trace for a single running CFML page request. While looking at running/active requests, just click on the button in the respective tool's interface to get a stack trace at taht moment of a given running request. As for how to make use of the result, see the resource above or the presentation I mention below. It's a powerful way to know what's happening at a point in time for a long-running request.

For those on CF 8+ Enterprise

If you're on CF 8+ Enterprise, you can take advantage of its Server Monitor, which also offers the ability to get a thread dump, by way of its "snapshots" feature.

I discuss the Server Monitor in a 4-part series of articles for Adobe, starting here.

Part 3 of the series discusses Snapshots in particular.

(I also have an an article introducing FusionReactor.)

The CF 8 Server Monitor can also provide the stack trace of a given request, but you need both "start monitoring" and "start profiling" to be enabled. If they are, you can see currently running requests in the Active Requests screen, and if you click on one, the stack trace appears in the middle of the request detail page.

But maybe you don't need to do a thread dump at all

All that said, I should point out that one of the values of thread dumps was to see what requests were running, which is incredibly valuable.

But if you do get either FusionReactor or SeeFusion, or can use the CF Enterprise Enterprise Server Monitor, note that they all have a feature to show what requests are running.

That, alone, can be what you really want to know, and their interface is a LOT easier to read than a thread dump. :-) And the stack trace feature let's you see exactly what line of CFML code a request is running at the time you request the stack trace.

Still, thread dumps can be valuable.

Getting thread dumps by email

Of course, you may not always be on (or be able to get on) the server when you want to see what's running. Here's good news:

All three of the monitors (FusionReactor, SeeFusion, and the CF Enterprise Server Monitor) offer an option to trigger sending you a thread dump by email when certain conditions are met (too many requests, requests taking too long, too little memory, etc.)

In FusionReactor, it's in the "crash protection" notification feature. In SeeFusion, it's the "active monitoring rules", and in the CF Server Monitor, it's the Alerts feature. See the docs or other resources for each for more information.

Non-request threads could be an issue

Also, sometimes a problem is not caused by a running CF request. It could be another thread that's having a problem, whether one of the scheduler threads (which are used for background tasks like the client variable purge process, and which have nothing to do with CF "scheduled tasks", which run as normal jrpp* or web* threads), or cf-thread threads (used by CFTHREAD as of CF8), and so on. This is another area where thread dumps (dumps of all the stack traces for all the threads) can be valuable.

Watching thread dumps over time

And whether watching the activity of running requests or other kinds of non-request threads, the key to understanding thread dumps (in addition to what is mentioned in the articles and presentations mentioned elsewhere here) is to view them over time (such as doing a refresh while viewing one interactively, or looking at two in a row if received by email.)

A tool to help analyze thread dumps

Indeed, Steven would also want to point out that Webapper (makers of SeeFusion) also have a free online tool called SeeStack which can help analyze thread dumps to make them a little easier to read.

Still more on thread dumps and stack traces

Further, the Adobe technote that Steven points to, Debugging thread dumps and server problems in ColdFusion MX 6.1 and 7.0, also gives considerable insight into understanding stack traces and thread dumps. It's also quite old and doesn't talk about things with respect to the more modern tools I've mentioned, but the information is valuable whether you use them or not.

In fact, much of it is about understanding stack traces (remember: a thread dump is a list of stack traces for all threads in the JVM), and connecting the dots in what they report and specific possible problems in your code or configuration.

I plan to do some entries in the near future, walking through use of these tools to solve common problems of CF servers being unavailable. Until then, check out also the "related entries" listed at the bottom of Steven's entry.

Of course, there are many other fine classic blog entries (and bloggers) who talk about CF troubleshooting, too. I also plan to offer something to help with finding those.

Update: I did a presentation on this topic, posted here. After reading the above, you may want to view that with more details on stack tracing any of many ways.

For more content like this: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, I can help via my consulting services
  • See that for more on how I can help a) over the web, safely and securely, b) usually very quickly, c) teaching you as we go, and d) with satisfaction guaranteed
Comments
I have been using Jboss a lot lately and there is a simple way to take a thread dump with twiddle that I outline in this blog posting. http://www.bpurcell....
# Posted By Brandon | 6/26/09 11:58 AM
Thanks for that, Brandon.
# Posted By Charlie Arehart | 6/26/09 1:11 PM
Charlie,

The link to the SeeStack is not valid. Can you please update that? And I’m sure it will be really helpful.
# Posted By Akbarsait | 11/11/09 5:53 PM
Thanks, Akbarsait. A quick google search turned up that it seems now one must add seestack.cfm on the URL. I changed it above.
# Posted By Charlie Arehart | 11/12/09 1:26 PM
Thanks for this blog post. I'm very glad I found it, as we're considering moving from MX7 Standard to CF9 Enterprise.

Another way to take thread dumps on CF6/7, which I've been doing for years, is to use a utility called SendSignal (http://www.latenight...). It requires console access - remote desktop in Window Server 2003 with the "Connect to Console" option enabled works also.

SendSignal <pid-of-jrun.exe> will write the thread dump out to the <servername>-out.log file in the runtime\logs directory.
# Posted By Jeff | 1/26/10 4:10 PM
Sweet. Thanks so much for sharing, Jeff.
# Posted By Charlie Arehart | 1/26/10 10:23 PM
Hi Charlie,

I'm facing one problem with my CF10 server shutdown in every 1-2 . After looking into log it seems the problem might be due to IIS Connector tuning problem and I have already made that changes mentioned here( http://blogs.coldfus... ). I'm just curious to know how can I enable thread dump if any error occurred and my server went down.

NOTE: There is chances that the request might be generated from CF scheduled tasks.
# Posted By Upen | 7/21/14 2:16 AM
Copyright ©2019 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting