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.

Ah, August, when thoughts turn to vacations...and end of summer sale-a-thons. :-) I want to share that the fine folks at Intergral, makers of FusionReactor and FusionDebug, are offering a 10% discount coupon code, CFCOMMUNITY, good through the end of this September.

I've written about both these tools quite a lot in the past, if you're interested in exploring my respective blog entry categories: FusionReactor and FusionDebug.

I've also written about them in the FusionAuthority Quarterly Update, if you happen to get that great magazine. Most recently I did, "FusionReactor: ColdFusion Server HealthCare (and What's New in Version 3)", in Volume ii Issue iv (Summer 2008), and a couple of years ago I did, "FusionDebug Explained: Interactive Step Debugging for CFML", in Volume i Issue ii (Fall 2006).

I'll also have news coming up about more cool stuff coming from the folks, including FusionAnalytics and FusionReactor Enterprise Monitor, both discussed in the FusionReactor Labs, as well as the recently released AIR Enterprise Dashboard, recently promoted from the labs to an available product.

Until then, go enjoy the discount code to get these great products, which help you with debugging and monitoring whether you run on CF 6, 7, or 8. (For more on why they still matter even with CF 8, see this previous entry.)

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.

As I wrote my previous entry on FR over the weekend, I got to thinking that some readers (whether new to FusionReactor, or using it but unaware of the datasource monitoring setting I mentioned) might benefit from a little more information about the FusionReactor's datasource monitoring feature.

What is the datasource monitoring feature? Why would I use it? Powerful stuff!

The datasource monitoring feature, referred to in the docs as the "JDBC wrapper", is a low-overhead way to configure FusionReactor so that it captures information about each query (against a given datasource), for every request, in detail and in aggregate. It captures and reports:

• the SQL statement (including CFQUERYPARAM values)
• the execution time (time spent in the database, and time spent getting it from the database to CF)
• the number of rows returned
• the CFML template and line of code where it was executed
• and more

This query information is tracked per request and also in aggregate across all requests (in the graphs in the Enterprise Dashboard and System Metrics pages, the Longest JDBC page, and other places.)

It's really powerful information to have when you're trying to understand why and how your page, application, or server it performing.

You can see more about using the information in these feature focus pages at the FR site: What are System Metrics? and Resource Graphs, among others.

As I said in the last entry, you can learn more about setting up the FR JDBC wrapper feature (including the simple steps on how to implement it--which have been updated in the FusionReactor 3 docs) in the Tutorial (pdf) and User Guide (pdf).

What's the overhead of this datasource monitoring? What's it doing?

That's a natural and reasonable question. The folks at Intergral (makers of FusionReactor) say that it's very low overhead, and they've done considerable testing (millions of requests before each release) to confirm it.

Maybe it would help to understand how it works. It's quite simple, really. When you configure a datasource to be wrapped (per the instructions pointed to above), you're basically just implementing an alternative JDBC driver (FusionReactor's) to literally "wrap" the driver that was being used originally by your datasource.

Your code continues to use the same Datasource Name, but the change of the datasource causes CF to pass the SQL first to the FusionReactor JDBC wrapper, which takes note of the starting time, the SQL statement, etc., and then passes it the query on to the real (original) database driver. That then passes it to the DB, and gets the result, and before it's passed back to CF, it goes back through the FusionReactor wrapper, which notes the execution time, recordcount, etc.

So you see, the wrapper is really quite lightweight. It's just an observer, watching what's going to and from the database. The info is then written to FusionReactor's JDBC log (if enabled) and stored in FusionReactor's small memory space for presentation in the various interfaces that show JDBC status information. Again there's more about this in the documentation.

Some other tips on the JDBC Wrapper

To see information on what queries were executed (if the datasource was wrapped), see the bottom of the request details page (for either a running request or the request history page). Further, note the available JDBC tab in that request details page. That will show each SQL statement and the details (time, count, etc.). The bottom of that page will also show counts and averages for all the queries in that request.

You'll see at the bottom of that page that you can also configure the JDBC settings page to restrict how many queries are shown in the JDBC request details, and you can limit it to only those exceeding a certain amount of time, as well as whether to show them in chronological order or executiontime order.

I'll note as well that if you do implement the JDBC wrapper feature, you'll probably want to enable JDBC logging, which is disabled by default. This writes all the detail above to a log file, for each SQL statement, which can be great for either post-mortem analysis (after a crash) or for trend analysis (perhaps across several restarts). You can choose to limit the logging to queries slower than a set number of milliseconds (separate from the control above about what queries to show in the request detail page.)See the JDBC>JDBC Settings option in the left nav bar of the FR interface.

The wrapper configuration for each DSN itself also offers still more features that many miss, so check out the docs. The Tutorial concludes with an example of using the rowlimiter feature to put the brakes on a rogue page, while the user guide details this and all the available features of the wrapper.

Learning more about FusionReactor

For more on FusionReactor in general, see their web site or my past blog entries on it.

(And yes, before anyone else would point it out in a comment, both the CF 8 Server Monitor and SeeFusion also provide this sort of JDBC query information. In the CF 8 Monitor, it's built-in (no need to configure the DSNs at all). And in SeeFusion, there's no need to manually configure each DSN, as there's a one-button configuration option. Intergral are said to be working on something similar for a future release of FR, so some of the concepts above apply across the monitors.)

FusionReactor works with ColdFusion Standard and Enterprise in version 6, 7, and 8, as well as Railo, Open BlueDragon, and BlueDragon/J2EE, and indeed any J2EE application server or Servlet engine. (BTW, technically, the term J2EE has been obsoleted by the more version-neutral Java EE or JEE. So many things in CF docs and related tools still refer to it as J2EE simply because most CFers aren't paying that close attention to such details, so there's been little motivation to make the clarification.)

PS: Why is it called the JDBC wrapper feature, instead of the datasource monitor?

That's an interesting question. It might feel a little clumsy calling it the JDBC wrapper. I wonder sometimes if CF users may miss the feature. Hopefully the explanation above about how it works helps. But you may wonder why it's not called the "datasource monitor", which might be friendlier for CFers.

But here's the thing: as I said a moment ago, FusionReactor is not JUST a CF server monitor. It can be used by any J2EE server or servlet engine. And not all J2EE app servers would use a concept of a "datasource".

Consider a Tomcat developer who might write a servlet or JSP that calls a database. They could leverage this JDBC wrapper feature (and all of FusionReactor's features) just as readily, though instead of changing the configuration of a datasource they would modify the JDBC URL in their code or a config file. That said, there are some J2EE servers that do use JNDI datasources.

So the makers of FusionReactor (Intergral) have to walk a bit of a fine line about labeling features in a way that might apply only to CF.

It's amazing, really, that one might not otherwise have any reason to notice that the product is designed to be used by either CF or J2EE shops. Most of us think it's just a CF monitor. It's much more.

And BTW, it's licensed per server, so you can install it on as many engines as you have (that it can monitor) on a single machine. In fact, you can even configure a free Tomcat engine just to be a monitor of other FusionReactor (Enterprise) instances.

This is something that Intergral is now offering (in beta) as a new packaging of the tool as "FusionReactor Enterprise Monitor - FREM". You can get it (or learn more) at their Fusion Labs site. I'll have more on that in a later entry.

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.

If you're using FusionReactor, and you set up a datasource to be monitored by it (the "JDBC wrapper" feature), did you know that you can configure it so you can see the datasource name for each query in the request details? A lot of people seem to miss it, so I wanted to point it out.

You just need to add the string:

;name=dsnname

to the end of the JDBC URL that you configure (per the instructions). For instance, for the wrapped version of my AdventureWorks SQL Server DB, I use:

That all goes on one line, of course, but I didn't want it to mess up the display in some browsers.

You can learn more about setting up the FR JDBC wrapper feature (including the simple steps on how to implement it--which have been updated in the FusionReactor 3 docs) in the Tutorial (pdf) and User Guide (pdf).

If you're not familiar with the datasource monitoring feature, I'll share more about it in a follow-up entry.

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.

The fine folks at Intergral, makers of the FusionReactor monitor for CF and other servers, have quietly released a new FusionReactor 3 today.

The key new features are:

• An improved Enterprise Dashboard, built on Flex, with additional new info and even an Air-based version (the latter still in beta)
• Substantially improved request metrics (system overview) page, with new graphs and data (since the Dashboard is only in the FR Enterprise edition, this is a real plus for FR standard users) and also slow query tracking
• dramatic new zoom feature in graphs, to zoom in a range of time intervals
• improved logging, especially useful for post-mortem analysis
• ability to fire a script/batch file when a server monitored in the Enterprise dashboard stops/starts (has long been able to send you email and/or log those events)
• support for multiple user logins with optional varying access levels, including new "manager" and "observer" roles in addition to the normal "admin" role
• abiliity to track cpu available in the system against CPU used by a monitored instance
• ability to view/delete requests queued by FR crash protection queuing

You can learn more about what's new, and upgrade pricing.

I'll blog more about many other little things that have changed--the good ol' "hidden gems" I like to do.

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.

Interested in learning more about FusionReactor and FusionDebug? I'm teaching inexpensive half-day classes (of my own design) every few weeks for Intergral, the makers of the tools. They organize the dates, take the registration and payment, and provide the GotoMeeting account that we use to present the training (over the web and phone). You can learn more about the training at their site.

Many know I'm also a big fan of the CF8 monitoring and debugging tools, but I've been talking about FD and FR for over a year. I've also written previously (since the release of CF8) on why there's still a place for all these kinds of tools. Perhaps the biggest point is that not everyone is ready to move right away to CF8, as good as it is. More important for some is that to monitor your production servers in CF8, you need CF8 Enterprise.

FD and FR work on all editions of ColdFusion 6, 7, and 8, and even offer some features not found in the built-in tools (though the reverse is true as well).

Here are the courses, which are 3 hours each for the full classes, and 1 hour for the free webinar.

FusionReactor FastTrack I - Introduction

The "FusionReactor FastTrack I - Introduction" class is more than just an introduction to the tool. It shares lots of tips and techniques for using the monitor to help solve real problems. More important, it shows many features that you might otherwise easily miss. Even experienced FusionReactor users would likely learn a lot.

FusionReactor FastTrack II - Advanced Techniques

The "FusionReactor FastTrack II - Advanced Techniques" class moves beyond learning how the tool works to how to use it to solve common ColdFusion performance and reliability challenges, including how to configure and leverage FusionReactor features to increase your server's performance, reliability and availability. It also covers how to access FusionReactor and its logs during and after critical periods, as well as common troubleshooting analysis approaches.

FusionDebug FastTrack I - Introduction

The "FusionDebug FastTrack I - Introduction" class introduces the tool, shows how easy it is to use, and demonstrates its advantages over traditional debugging techniques as well as tips and traps in using the tool. It includes debugging CFML code called from client-side applications like Flex and Ajax. In fact, someone interested in learning about the CF8 debugger could get a lot from the class (since they're so similar), though it's just focused on FusionDebug.

Free FusionDebug Webinar

The Free FusionDebug Webinar in an online seminar where you can learn about how to debug CFML with FusionDebug.

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.

Here's news that will interest those who may have become interested in interactive step debugging in CFML, since CF8 includes it. If you're not ready to move to CF8, you can get CFML debugging for free with CF7 (or 6 or 8), with FusionDebug, the commercial tool from Intergral which was the first to give us step debugging in CFMX.

It's just through November, but if you buy their sister product, FusionReactor (the Enterprise edition), you'll get a free copy of FusionDebug. For more, see:

http://www.fusion-reactor.com/fr/offer.cfm

You can learn more about FusionDebug from several blog entries I've done in the past (see the "related entries" area at the bottom of this entry), including one on why I don't think CF8 is a death knell for either FusionDebug or FusionReactor.

(So no, I don't think anyone should read this as a move of desperation on Intergral's part. Rather, it's natural that the release of CF8 will cause some to say, "well, I could wait for CF8", but then for many shops moving up to a new release isn't trivial. That's why I said above: this may be most compelling for those whose interest in CFML step debugging has been piqued, but they can't for some reason move to CF8, whether Enterprise, Standard, or Developer. And of course, there are times when even a developer edition doesn't help if you need to debug a central development or test server. See my past blog entries on pros and cons of debugging a shared server. There are also some differences between the two that may even keep some using FD on CF8. More on that in a future entry, perhaps.)

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.

I'm surprised to still see people lament when they learn that CF8's server monitor does not run on CF8 Standard, or that it doesn't run at all against CF 6 or 7. My surprise is that their comments often make no mention of being aware of alternatives. On one list, someone said they might even be willing to pay double CF Standard's price to get monitoring in Standard. They just didn't like paying 6 times more (for Enterprise).

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.

If you're a user of (or are considering using) FusionDebug or FusionReactor, two tools I've written about before, I want to point out that they have some new support resources.

Mailing Lists

First, there are now mailing lists (Google Groups) for each. This is something I pressed for since last year, and thankfully now they're enabled and there are good discussions already taking place.

http://groups.google.com/group/fusionreactor

http://groups.google.com/group/fusiondebug

Knowledgebase, Searchable and Browsable

There is also a new Knowledge Base where they've put many tech notes and answers to questions (other than those already in the FAQs). You can search it via the main support page, indicating which product and type of docs to search (it also searches the Google groups as well).

Finally, I'll share a little hidden gem. If you'd rather not search the KB, you can instead browse it. Here's a URL for each product:

Browse FusionReactor KB articles

Browse FusionDebug KB articles

I should note that they don't currently offer these links on the site, and in fact they may change in the future (since they're not published yet), but I don't think they'll mind me sharing it for now.

They're presented in numerical order, which isn't really chronological order, but clearly mixed in are discussions relevant to both old and new releases of the products, to be sure to note that indicator in the info at the bottom of each technote, if you have any question. There's some good stuff in there, and I'll be mining it for tips to share (here or on the mailing lists).

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.

So by now most have heard that Adobe announced at cf.Objective() that Scorpio (now CF8) would include an interactive step debugger. And many may know I've long been a fan of FusionDebug, having written quite a bit about it, as well as the monitoring tools, Integral's FusionReactor and Webapper's SeeFusion.

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.

As I alluded to a couple of weeks ago, I'm now in the midst of a two week swing through Europe speaking at user groups and the CFDevCon conference, as well as teaching a couple of day-long classes. See the links below for more info. But here's where I'll be. If you're in the area, please come by and say hello:

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