Note: This blog post is from 2010. 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.

"CF911: Stack Tracing CFML Requests to Solve Problems"

Regardless of what CFML server monitoring tool(s) you have, or even if none, did you know that you can use a feature called "stack traces" to be able to pinpoint the exact line of code that a CFML request is running at any time? Did you know how to use that information to troubleshoot performance/stability problems? Do you know how to obtain that information either manually or automatically (such as during a crash while you're not watching)? Do you know how to obtain that information in any of the CFML Server Monitors (FusionReactor, SeeFusion, the CF8/9 Enterprise Server Monitor), or with free command line tools? And how to do this for any CFML engine (CF, Railo, BlueDragon, etc.)? Do you know how to interpret the information once you get it?

In this session, veteran CF troubleshooter Charlie Arehart will help remove the mystery from using stack traces. It really is amazingly simple with the right tools, and it can be incredibly useful to solve otherwise thorny problems, once you understand how to interpret the information.

Of course, I'm thrilled to be heading back to Minneapolis. I spoke there previously in 2008 and 2007 but couldn't attend in 2009. It'll be great to see all the fine folks who run and attend this unique conference.

BTW, I just saw also that CFUnited announced another round of topics accepted today and I see a topic whose title if very similar, "How to Read a Stack Trace", by the inimitable Daryl Banttari. It's hard to tell from his brief description how similar these will be, but Daryl is awesome so I'm sure I'll learn much from his. (I was literally just about to offer mine as another CFUnited submission but now won't of course. :-) Hopefully another of my submissions will be accepted, so I can keep my streak of having spoken at every CFUnited since they started.)

Anyway, the good news is that whichever conference you go to, this important (and often misunderstood) topic will be covered! :-)

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.

Well, there are several ways you can watch them, as this entry will discuss, and some may be better suited to the job than others. It can be very interesting to discover what's going on, especially if you're having any suspected performance problems which you think may be related to ORM processing (or just if you wonder what all it does for you).

[....Continue Reading....]

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.

For readers not familiar with FusionReactor, it's a server monitor (and more) for CF, Railo, OpenBD, and indeed any J2EE/Java EE server. I've written and spoken about it a lot. Here is the link to the category of my blog entries about it.

As for 3.5, here is what has been shared in an email to their customers. I wanted to pass it along to everyone:

[....Continue Reading....]

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.

(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.)

[....Continue Reading....]

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.

Basic CF Monitoring in Nagios

First let me share that if you've not explored monitoring CF with Nagios at all, here's at least one blog entry from 2005 discussing that. (A more recent one, at http://profec.net/2009/01/12/monitoring-coldfusion-with-nagios/, which I used to list here, is no longer responding, nor could I find it on archive.org.)

Of course, you can easily use Nagios primarily to report whether CF's up or down, but you can also monitor basic statistics such as are provided via CFSTAT (also available on Windows via Perfmon, which also exposes generic stats about all processes), as demonstrated in that blog entry.

But you may have noticed that, if you run the Multiserver (multiple instances) version of CF, those CFSTAT and Windows Perfmon Stats aren't available on that version of CF.

So what to do if you wanted to monitor more about what's going on inside of CF?

FusionReactor Nagios Plug-in

If you're running FusionReactor Enterprise, you can now get that additional information via the free FusionReactor Nagios Plugin. It's a perl app that when implemented will expose certain key statistics in a way that Nagio can process them (and some are things that CFSTAT and the CF Permon stats don't report):

• Count of current running requests, and total count of all requests run
• Count of request queued by FusionReactor
• Average request runtime (since server start), and Recent request runtime (in past 60s, by default)
• Count of recent slow pages
• Memory free in bytes and percentage
• Memory Total and Max
• Instance and System CPU Use percentage
• Count of recently completed JDBC requests

Note that this is technically community-contributed feature (from an Intergral employee, David Stockton), not a supported feature.

If you're running or are interested in FusionReactor Enterprise, check it out.

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.

Besides a fresher appearance there's improved organization and navigation. There are high-level views of the products (available on the front page, with tabs along the bottom for each product) and more detailed pages on each (FR and FD), with product tours, benefits, faqs, and much more. This breakdown of high-level and detail views applies as well to discussions of the Air Enterprise Dashboard and their Services (consulting, training, etc.)

Through the updated web site you can also learn about many other resources available, including articles, videos, and blogs by them and others; product docs, screenshots, FAQs and more; info on customers and free/paid support; community tool contributions, and lots more.

The folks behind FusionReactor/FusionDebug are really great. They're very open to communications and always welcome (and act effectively on) feedback. I've been a long-time fan, so much that I work with them directly on doing training and consulting based on their products (while remaining an independent consultant.) It's their very openness and willingness to listen to feedback that brought me to working with them more and more closely over the years. I'm glad to help others take notice of the company and their great products.

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.

Well now you can, if you have FusionReactor, by way of a simple 2-step process to configure CF to do this. You can learn more about it in this article Capturing ColdFusion's Debug Output in FusionReactor by Darren Pywell, CTO of Intergral (makers of FusionReactor).

In it, he explains what this is all about (a combination of using FR's API and the "markers" feature of the FR Request Detail page, in conjunction with CF's built-in feature to let you add and use new debugging templates). More important, he gives you all you need to know to set things up, from the simple snippet of code needed (downloadable) to a walkthrough of the simple steps needed to configure CF to hand the debugging output to FR. You can be up and running with this new capability in a matter of minutes (skip to the bottom for the "fast track" steps he offers, for proof.) Check it out.

But what about the performance impact?

And yes, he addresses briefly the performance and memory implications of using such a feature in production. You should certainly take care to ensure that doing this isn't causing any harm, especially if doing this in production. That said, I see lots of shops that leave debugging turned on and use the IP address limiting feature in the CF Admin, which many will argue is equally detrimental. I think a point to make is that the negative impact may be more "theoretical" to some than to others.

The bottom line, as he recommends, is that you should test such things before rolling them into production. Sadly, many shops can't or don't bother with testing (which is very unfortunate).

If you can't test the impact, measure it...with FusionReactor

At least then you should try to have some measure you can watch to see if processing is being in any way harmed, whether it's tracking fewer requests being processed per day, requests taking longer to run each time on average, more CPU being used by CF per day, and so on.

The very good news is that those who have FusionReactor can use FR's own tremendous logging to help report this kind of information. I talk about how to report against that using a tool like Microsoft's free Log Parser, in this page on the google group for FusionReactor.

I'll do a future blog entry on the tremendous logging that's possible. It far exceeds anything provided by any other tool, including the CF8 Server Monitor (which does no logging at all), and it does it with very low overhead.

So if you're using FusionReactor, check out the debug tool. It's very easy to enable and disable (via the CF admin, once you've added the new debugging template). It's also a useful demonstration of the FRAPI.

And if you don't have FusionReactor, check that out, too. I use it or help people use it every day to solve CF problems. It's much more than "just a monitor". For more info, see the site's many resources (brief feature highlights, docs, online help, a live demo, mailing list, and more). See also some of the other entries I've done here on FusionReactor.

Note: This blog post is from 2008. 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.

[....Continue Reading....]

Note: This blog post is from 2008. 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.

Check out the JDBC Wrapper Tool. For now it's technically a "community contributed" tool (not in labs, and not from Intergral as a formal product). But it was written by an Intergral employee, Dave Stockton, and the company is very interested in your feedback about it. (Intergral is the company behind FusionReactor and FusionDebug.)

Check out the page for the download, docs, screenshots, a change log, tested databases and CFML server configirations, and more. (And note that it's not just for CF, but is intended to work with others. Railo support is listed coming soon **that's an update from the original post, where I said Railo support was there**.) If you can try it on other DBMSs and CFML servers, they'd welcome that input.

For those who have needed to monitor/wrap datasources, especially many, or on many servers, this is a real gem. Whether you are or not using a supported server, it's worth a few minutes of your time to check things out. I've used it, and it worked great.

For those not sure what this datasource monitoring/wrapping is all about, check out an entry I wrote earlier this year, What is the FusionReactor datasource monitoring feature? Why would I use it? Powerful stuff!. Both that and the docs I link to will give you more info. The datasource monitoring really is really a great tool for troubleshooting and trend analysis.

Note: This blog post is from 2008. 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.

FusionReactor: ColdFusion Server Healthcare (and What's New in Version 3) (PDF)

Thanks, folks! I hope it might serve as a useful intro for those who've not seen the tool (whether in its older or newer version), which can be used to monitor CF 6, 7, and 8. That CF8 support is important not only for those running CF8 Standard, which doesn't have the CF8 Server Monitor, and also even for those who can run the CF8 Server Monitor, as there are some useful benefits of using it even on CF8 Enterprise). Note that FR also works with Railo and OpenBlueDragon, as well as BlueDragon/J2EE and indeed any J2EE application (including LiveCycle Data Services) and any J2EE engine (JBoss, Tomcat, WebSphere, etc.)

The article can also serve as a review of features that those already using the tool may have missed, or you can focus on what's new in FR 3 (quite a bit).

Check out the article, and the tool, including the available live demo in addition to the 10 day trial. I'll note that the live demo is running at a lower level of authority (one of the new features of FR 3), so you don't see and can't do all with it that you might as a full admin user.

I'll arrange to do a demo of the tool on an upcoming CF Meetup session, whether on its own or along with other monitoring tools for CF which I've discussed before.