[Looking for Charlie's main web site?]

Helping Joe Rinehart and his wife Dale

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.
While some may have seen this news in the past weeks, it bears repeating for some who may have missed it. Joe Rinehart's been a stalwart member of the CF community for some years, known most perhaps for his work on the Model-Glue framework.

Well, sadly, his wife Dale has been diagnosed with Multiple Sclerosis, something he's made public on his blog. In addition to his sharing his experience there, she's has been journaling her experience and emotions on their blog. I'm sure many are finding comfort in their incredible strength and fortitude in the face of such a trying experience.

Still, the costs for treatment will be monumental, and so a group of CF community members have gotten together to create a site, www.helpsupportjoeanddale.com offering a way for those interested to offer donations to help offset those costs. So far the collections have been going really well, and all the money goes to them directly.

You can even watch a short video at the bottom of the page where Joe and Dale express their appreciation for this outpouring of support. All this was a surprise for them, and it's been a touching testament to the greatness of this community. I wanted to wait a couple of weeks to put the news out there again for those who may have missed it the first time.

If a tree falls in a forest and comments are disabled, how will you know? (COMMENTS WORKING AGAIN)

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.
Oy, computers. Have you by any chance tried to leave me a comment here on my blog? Or tried to do a search of the blog? Sadly, neither would have worked. In the case of the search, it just never limited the results to entries with the search text. In the case of blog comments, it just kept showing the form and ignoring what you typed. I'm really sorry for any who may have been entering comments all this time, to no avail.

When I noticed I was getting no more comments, I knew something was up, and it turns out both were caused by the same thing. The issue was that a couple of weeks ago I switched my site to a new server (more on that later), and in the midst of the move I made a slight configuration mistake.

The bummer is that no one ever wrote met to tell me that their comments weren't taking. I offer my email address in a pod on the right of all pages. :-( Oh well. Problem solved now.

Tracking number of CF sessions per application easily, and why you should care

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.
Ever wanted to count how many sessions are active on your server, in total and per application, whether on CF 7 or 8? And regardless of whether you're using CF's regular sessions or the "new" J2EE sessions feature introduced in CF 6? Would you be surprised to find you could have a shocking number of active sessions?

Here's a nice simple solution, the free ServerStats tool, that provides that info. It's from Mark Lynch (of Learnosity) and while a couple years old still works just fine. Besides printing out the total count of sessions and the count per application, ServerStats also shows some information about CF memory use, number of processors, and more.

Update: Mark's blog is since gone, but that link from the archive.org shows how the page appeared in 2015, and the link to download the zip for the code does work there.

It's totally safe to use (I've helped hundreds of customers use it in my troubleshooting consulting practice), and the CFML source is open for you to review.

Of course, some will want to point out that the CF 8 Server Monitor offers session and memory info, but for those not on CF8 Enterprise, this is a useful alternative. Also, some may want to point out that the solution described here uses internal objects that may be disabled (and are also undocumented and unsupported). I discuss both these points below. There are also some other approaches people take, which I also mention briefly.

Why care about number of sessions?

So why care so much about how many sessions are active on a CF server? If there are 10 or 20, or maybe a 100, does it really make a difference? No, not likely. But what if you find that there are 90,000? I'm not kidding. I was helping someone just last week when we discovered this. It's not as unusual as you may think.

Often when I'm helping people solve problems with their CF servers, one of the first things I want to help them discover is just how many sessions they have active at any time. With the potential impact of spiders and bots creating huge numbers of sessions, which could have an impact on memory and also on other aspects of performance, it's definitely one of the first things to look into.

So how's Mark's code tracking them?

Mark's blog entry (pointed to above) is a summary of things he'd discussed in a few blog entries about how to leverage internal CF/Java objects to provide the info, and that one entry offers ServerStats as a downloadable zip with a single CFM file and a directory of CFCs and custom tags. You can just extract the zip into a web-accessible directory and run it. No need to create custom tag mappings, etc.

Many folks have known about and blogged about these internal CF/Java objects, coldfusion.runtime.SessionTracker and coldfusion.runtime.ApplicationScopeTracker, over the years. They're undocumented and unsupported, so you use them at your own risk, but again I've confirmed that Mark's code works against CF 7 and 8 (and I'll assume 6 as well.) You can google to learn more from him and others on these.

CF8 Enterprise has other solutions

Of course, those on CF 8 Enterprise (or Developer) have still other approaches to this, whether in the CF8 Server Monitor (see its active sessions page) or the Admin API's servermonitoring.cfc. But if you're not CF8 Enterprise (and even if you are) this solution can help.

Update: FusionReactor Extensions for CF

When I first wrote this entry in 2009, FusionReactor did not offer any session tracking, but does since the introduction in FR4 of FREC (the free FusionReactor Extensions for CF), which added tracking of CF sessions in its realtimestats.log. For more on that, see my blog entry, Tracking #ColdFusion sessions within FusionReactor, by way of FREC logging.

Finally, note that in FusionReactor 5, the FREC functionality is built-in, and besides the logging of session count in realtimestats.log, there is now a chart of sessions offered in the Metrics>Custom Series option on the left. Choose the option for ActiveSessionCount in the drop-down on the top right, if it's not selected by default.

(For any who may wonder, SeeFusion does not offer session tracking info.)

JRun Metrics and other solutions

And yes, there's still another way to get at least a count of all J2EE sessions, using the available JRun Metrics. While it has the benefit of tracking the info over time, it does track the session count only if you've enabled J2EE Sessions in the CF Admin, and even then it tracks only the total of all sessions, not a count per app.

Of course, there have been various solutions offered to solve the problem of session tracking, such as those that track sessions in code (within your application) by storing them in an array in the application or server scope, and so on. The nice thing about using the internal CF/Java objects is that the apps being tracked don't need to be altered at all.

Potential Security Gotcha

Of course, therein lies a potential security risk. Anyone running such code on any CF server can have access to the sort of info that these internal CF/Java objects offer. The example above (Mark Lynch's) doesn't really expose much to worry about (unless the names of apps on a server is sensitive, where one user on the server shouldn't know that another app exists on it, which may be true in a shared hosting environment.) But more important, if one digs deeper into these objects, they do expose more details, including the values of variables in session scopes across all applications. That could be considered very sensitive.

As such, there have long been a couple of solutions that Adobe has provided to enable an administrator to shut down the use of these internal objects.

First, in CF 5 and above, it's been possible to set security for the entire server (or a given app in CF Enterprise) to make it impossible to call any Java objects (yes, you could call Java objects starting in CF 4.51). To learn more about this option, called Resource Security in CF Standard, and Sandbox Security in CF Enterprise, see my 2-part article series for the Adobe Security Developer Center from Sept 2002, "ColdFusion Security, Part One: Understanding Sandbox/Resource Security" and "Part Two: Sandbox/Resource Basics", both available at my articles site.

That approach is a little brute-force though, and throws the baby out with the bathwater if you have legitimate use of java objects.

So in CF8 finally, Adobe added a new feature that permits an Administrator to disable JUST access to the these underlying internal CF/java objects. See the CF Admin "Server Settings" section, "Settings" page, and its "Disable access to internal ColdFusion Java components" checkbox. The option takes effect immediately.

It's certainly more effective if one wants to control to this info, but of course it will make code that relies on it fail, with an error like:

Permission denied for creating Java object: coldfusion.runtime.SessionTracker

I'll point out that since most of the folks I help with run their own servers, they're just not worried about disabling these internal java objects, since they can control what code runs on the servers.

So if you want to quickly find out how many sessions you're running, per application, check out Mark's code. You can also get much more info from these internal objects, if you want to explore. I'm working on a tool to provide some still more powerful information that I started working on years ago based on these objects. But until that's ready, I had occasion today to point out this working alternative to a customer, and thought I'd pass it along here.

Want to view CF debugging output for all running requests? Send it to FusionReactor

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.
We all know that showing debug output to end users is a no-no, but sometimes don't you wish you (as an admin) could have access to what debugging info the users would have seen while their requests are running? What if you could capture the debugging info to view it for all running requests, and better still, keep it for a short time to view about hundreds of recent requests?

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.

Recap of the 40 Online CF Meetup talks for 2008

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.
As many in the CF blogosphere reflect on the past year, I figured I'd follow suit with a recap of the 40 talks we've had in 2008 on the Online ColdFusion Meetup. you can find the title and links to descriptions and/or the recordings for each talk below.

Always seeking more speakers

On behalf of the meetup members, I certainly want to thank all the speakers. Still, as I say in each meeting, we always welcome speakers on any topic related to CF, new or old, beginner or advanced. With now over 1600 members, there is an audienced for virtually any topic. Whether you're a first time speaker, or an old hand who may have talks that our listeners maybe haven't heard, please consider coming to speak. We tend to meet Thursdays at noon and/or 6pm EST, and we can change that time if it doesn't suit you. Please contact me or see this page of info for prospective speakers.

The 2008 Topics and Speakers

If you're curious about other talks we've had, see the list of talks in 2007.

Again, thanks to all the speakers and attendees, and here's to much more in 2009. We already have several speakers lined up for January, and I'll be announcing them soon.

Copyright ©2020 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