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

Also, sorry for the long delay in blogging. Just been so busy doing my CF server troubleshooting consulting.

As for my sessions at CFSummit (next week), I'll be doing the following (and you can follow the links to learn more about the talks, their dates and times, etc.):

• Hidden Gems in ColdFusion 11
• Monitoring CF: What are my options and why should I?

At CFCamp, the following week, I'll be offering:

• Hidden Gems in ColdFusion 11
• Monitor, Troubleshoot & Protect Your CF/Railo Servers with FusionReactor 5

I had also presented the Hidden Gems talk at NCDevCon 2014.

These are all great conferences, and, in addition to cf.Objective 2014 (where I spoke also, on different topics), they are each great ways to keep up on what's going on in the world of ColdFusion and related technologies.

Finally, if someday you're visiting this blog entry and find that one of the conference links no longer work, you can find my own link to all my presentations, at all conferences the past 15+ years (as well as to any recordings made available) at my presentations page.

Come say hello if you're at any of these events.

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

But as is often the case in a lot of the CF server troubleshooting consulting I do, I find the causes to be far less often what most people seem to suspect. So what would I look for when someone reported high CPU in ColdFusion (or Lucee or Railo )? Read on.

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

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

Yet people will reasonably want to be able to have some mechanism that "watches" CF "from the outside", to know when it's gone down. How can you do that? That's what I'll point out in this entry.

And beyond talking about what goes along with the CF Enterprise Server Monitor, I'll also point out options for those who are NOT running CF 8, 9, or 10 Enterprise and therefore do not have the Enterprise Server Monitor. This also includes those CF 6 or 7. There are solutions for you, and also for those running Lucee, Railo, BD, or indeed any Java server. More on all that in a moment.

This is part 4 of an unexpected series of entries today on the CF Enterprise Server Monitor. :-) I got on a roll, and each seemed deserving of its own topic. See the "Related Blog Entries" below this entry for links to those.

What the CF Server Monitor is, and is not

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

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.

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

(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 2007. 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 here's the thing: you can indeed get CF server monitoring, whether added to CF8 or made available in CF 6 or 7, and for far less than even double the cost of CF Standard. Some of you know where I'm going, but in case it needs to be said...

Check out FusionReactor and SeeFusion, both tools that I've written about before (see the "related entries" links at the bottom of this entry.)

Both these tools not only run on 8 (any edition), but they run on 7 and 6 as well, which CF 8's monitor does not. Further, FusionReactor can monitor not just CF but also any J2EE servers or app (including LiveCycle Data Services, for instance), and SeeFusion has a sister product, SeeJava, that can do this as well.

I've been a huge fan of both tools for a couple of years. No, they're not identical to CF8's monitor, and CF 8's monitor has access to a lot of information that those tools don't (for now, though they could be modified to access it as well, via the Admin API if running on CF8 Enterprise). But even until then there are features each of them has that CF's monitor doesn't, and vice versa.

I know some instead want Adobe to offer the monitor somehow to those on Standard, whether at some price or in some new edition. The chances of that seem seem pretty slim for now, though certainly interested folks should make their concern known. And certainly, it's worth noting that one can run the CF8 monitor on the Developer edition.

But some rightly point out that they want CF server monitoring in production and they can't use Adobe's on CF8 standard (or on 6 or 7). (And they're asking for more than just monitors to tell if the server's up or down, etc. Sure there are plenty of tools to tell that, but they want real insight into the processing of requests, threads, queries and more, which only these tools can do.)

I just want to make sure those folks know there are indeed good, professionally managed alternatives to get that on CF8 standard and earlier versions of CF, and those options are at low costs and come with free trials. (Same goes for step debugging. While the new debugger in CF8 works only with 8, FusionDebug, from the same company that makes FusionReactor, works in 6, 7, and 8.)

As I wrote before, I don't feel that the availability of the CF8 monitor (or debugger) diminishes the value of the third party tools for those on CF8. Keep an eye on the monitoring category here in my blog as I'll continue to write more about all 3 monitors in the future. They each have their strengths and their place.

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

A natural question on the minds of many is whether Adobe's entry into these markets is a death knell for these vendors? I don't think so, at all. Here are just a few reasons why. I'm sure I (and others) will think of more. Comments are indeed welcome.

1. Are you running 6, 7, or 8? - First of all, it's vital to keep in mind that the new CF 8 tools work only with CF 8. If you're still on CFMX 6 or 7, then you can't use the CF 8 debugger or monitor. I've heard some who thought that the new CF 8 Debugger might work worth the earlier releases. It does not. Of course, it's indeed another strong incentive to move up to CF 8, and there are more and more reasons being released all the time. But until you do, you can't benefit from them. Both SeeFusion and FusionReactor/FusionDebug work with CF 6, 7, and 8 (and the monitor tools also work with BlueDragon/J2EE and should work with Railo, Smith, and others.)

2. Do you have more than just CF to monitor? - Indeed, another point in the favor of the third-party monitoring tools is that more than just CFML servers, they indeed work with any Java server. And that's not just tools like Tomcat, JBoss, WebLogic, and WebSphere, but also includes other Adobe-specific tools that are also J2EE server-based, like Flex/LiveCycle Data Services, the older Flex 1.5, and more, and of course the Adobe J2EE server, JRun. FusionReactor's installer and "add server" feature will both recognize any of these automatically so that the one FusionReactor Enterprise Dashboard monitor can watch all such services, while SeeFusion offers a separate SeeJava product for watching such J2EE servers.

3. Does one size really fit all? - Another point to keep in mind is that each of the tools still do something that the other does not. I've said the same when contrasting SeeFusion and FusionReactor, and I can now say the same of them and the new CF 8 tools. Each can have their place in a developer/administrator's toolbelt. I could even argue that one could/should have them all, for whatever benefit each offers. The prices are low enough that it's not much of an issue.

4. CF 8 monitor API is public - With regard to the new monitor in CF8, Adobe has made it clear that it's just a particular (albeit very nice) Flex interface on top of an underlying API of admin CFCs that anyone can call. Naturally, this means that the other monitor tools could easily add whatever feature they (or users) may think must be added. (The FusionReactor folks will announce plans at CFUnited for integrating CF8 monitoring features into FusionReactor, so we should see some benefits and cooperation taking place.) Again, though, perhaps the reasons above may diminish the significance of needing to "keep up". Perhaps they can peacefully coexist.

5. If a tree falls in Times Square, it will make a sound - One can argue that a benefit of the new CF 8 monitor and debugger tools is that they will raise the profile of--and interest in the CF community for--such tools. And of course competition also breeds innovation. I think we already saw that between the two monitor tools themselves (and indeed between CF and BD, and others). In fact, still another outgrowth of this will be an increase in the opportunities for skilled folks (like those at these companies) to help CF developers make the most of the mass of information that these tools all provide. That will serve both companies well, since they each do training and consulting.

6. The past is prologue - Further to the last point, let's keep in mind that we can only compare the new CF 8 tools to the current versions of their third-party counterparts. Both Intergral and Webapper have told me (and others) that they've known these things were coming and have been considering enhancements for quite some time. The companies will be in a great position to watch and see what things people like (or don't like) about the CF 8 tools. I mentioned Intergral's plans above, and the SeeFusion folks are talking about extending their product to provide actual problem-solving intelligence, beyond just exposing metrics. Of course, we can expect Adobe will continue to evolve the tools as well (both before the final release and in later ones).

7. An abundance of riches - Finally, consider how fortunate we are in the ColdFusion community to have third party vendors who take risks to enhance the CF toolset and bring new and exciting professional tools to market--even before Adobe! We should support them if indeed they provide solutions to our problems. To the degree that we do (and they do), they will continue to survive.

Clearly I'm high on the entire CF tools market and think there's a place for all the companies and their tools.

Even so, there are some things that the CF8 monitor and debugger do add that are not currently in the other tools, and there's no doubt that for many, if they're moving to CF8 they may be happy with what they get built into those tools.

But it's not a zero-sum game with only one possible winner. Even if only a small fraction of the market remains interested in and using the 3rd party tools, whether because using the older CF releases, or for the features they offer, that's still a decent market for the toolmakers. And as they (and the market) evolve, the third party tools should continue to gain new fans.

I'll be writing (and speaking) quite a bit about both of the new CF 8 tools, as well as those from the other vendors, and how they all compare now and into the future.

It's just more testimony of why it's now really a great time to be involved in CFML.

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

Both SeeFusion and FusionReactor are based on an underlying java-based mechanism called Servlet filters. On the surface, it might seem that things should work since the standalone versions of BD are built atop ServletExec (just as CFMX standard and enterprise standalone editions are built atop JRun).

Sadly, the edition of ServletExec that New Atlanta chose to bundle under BD (a choice made a few years ago) does not support servlet filters. ServletExec itself has indeed supported servlet filters for a few years; it's just that New Atlanta never had any motivation to update the version that was underlying BlueDragon. Who knows if that may change in the upcoming BD 7.

The good news is that it seems you can indeed use both SeeFusion and FR with BD/J2EE. I've previously done the former, and my reading of the FR docs for now suggest it would work fine. The installer guide for FR has a section on "manually installing FR", and where it discusses the directories to be updated for working with Tomcat and Jboss, it's really the same info that would apply to BlueDragon deployed on those servers (or any like them). (I've tried it tonight and hit a snag, and the guys from FR are working with me to get through it. I'll update with a comment here whatever I find.)

Finally, of course, BD.NET doesn't support servlet filters at all, so you can't use SeeFusion or FusionReactor on that product.