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.

Or same with if you've set the request to timeout using an alerting feature in a CF monitor like CF Enterprise server monitor, FusionReactor, or SeeFusion.

And perhaps you've seen this error from ColdFusion, in your logs or on-screen:

Do you know what this means? It's usually not what you think, and it may appear as I said 3 hours after a request was "supposed to timeout" in 60 seconds. I've even seen experienced CF developers who get thrown by this challenge. It's not new (and for those reading this even in the CF2016 era, it still happens). And it's not so much a "bug" (in either CF or the monitor tools) but just a situation that you need to understand, and there can be some ways to resolve things.

In this entry I'll try to help explain this surprisingly common problem and I hope to correct some equally common misconceptions. I'll even contend that the info in this error message is often useless and indeed misleading (and therefore the feature producing it ought not be relied upon completely, and should perhaps even be turned off for many). More important, again, there may be a way to "really" kill such a long-running request. Along the way, I'll share some things that I've not seen documented elsewhere.

I also share a solution that may work for query processing but it's NOT about a tag attribute but rather a CF Admin setting in the datasource "advanced settings" to set a "query timeout". This was added in CF 9, but many never noticed. If that's your problem and you want to skip to more on that here, feel free. but you may want to come back and read the rest as it is STILL not a perfect solution.

Strap on your seatbelts. We're going for a bit of a ride (if this situation was easy to understood in the length of a tweet, then perhaps everyone would already understand it and not find it challenging!) As always, I welcome feedback.

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

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.

Did you know there is now a setting in the DSN page of the CF Admin (for most of the Adobe-provided DB drivers) which allows you to set a maximum timeout for queries against that DSN?

It's a new feature enabled for the DataDirect drivers, as updated in CF 9. (You will not see it if you use an "other" datasource type, such as when using a downloaded JDBC driver that you implement on CF.)

The caveat? This timeout is ONLY settable there in the DSN definition, not in CFQUERY (or CFSTOREDPROC) itself, which is a shame. The existing TIMEOUT attribute for those (CF10 added it for CFSTOREDPROC) is not the same and generally does not work. Still, the value of this even at the DSN level is too important to ignore for some challenges. More on that (and some other thoughts) in a moment.

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

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.

While you can find the details (and optional RSVP info) on the meetup event page, I'll repeat the description to save you having to go there:

[....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.

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.

[....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.

The problem outlined here has to do with being careful when you're modifying CF to enable/disable RDS (or doing any edits in the [cf]/wwwroot/WEB-INF/web.xml file that controls it.) This applies to CF 6, 7, or 8.

[....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.

[....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.

Sure, there are many DB monitoring tools out there, but Ignite focuses on tracking, analyzing, reporting, and explaining wait events within the database--and you'd be amazed how often waits caused by your code, that of others, or from other operations in the DB are the explanation for poor performance. It can help target exactly what SQL statement or other operation is a cause of significant waits.

The tool presents the data aggregated over time, so you can view it per hour, day, week, etc. Great for both drilling down to find hot spots, and for viewing how coding/config improvements (resulting from your responding to the analyses) have led to performance improvements over time.

The tool runs with low overhead: it reads data that the DB provides, storing it in a database and providing a web-based interface to view that data. The process to read the data and create the repository (and present the web-based interface) can (and should) be done on a server separate from the server being monitored.

Here's a nice 2-minute demo. There's also a free trial, of course, and it's pretty quick and easy to install and benefit from.

As I noted in the title, it works with SQL Server, Oracle, DB2, or Sybase (sorry, not MySQL. Don't know why). And while it's a commercial product, it's not a ridiculously high price (as for some tools). I just learned of it in the past few weeks, and one customer of mine who tried it has been just thrilled with the results. I hope to write more about it later, but wanted to at least get this info out for folks to consider.