I will propose that they should be done from oldest to newest. Here's why.

If you look at the list of CF security hotfixes offered here, you may wonder whether to start with the most recent ones, or the oldest ones. If you look at their respective technotes and zip files closely, you may find that some are truly independent of the others. But it's also a reality that some do supercede the others. That may be obvious to some, but I wanted to offer a case in point.

Consider the hotfixes for APSB11-14 and APSB11-04. If you look at the zips for these, you may notice that they offer a few files (in the web-inf/lib directory) that appear identical in name (log4j.properties, esapi.properties, validation.properties, commons-fileupload-1.2.jar, and so on.) If you had applied the later one first, you may then wonder if it's significant if you then want to apply the older one.

Well, those files are in fact identical (I did a compare). But the files in the CFIDE associated with each hotfix are in fact quite different and so the later ones would supercede the earlier ones.

So you would NOT want to do them in the wrong order (older before newer). It's just not always clear from the technotes whether this is an issue to worry about, so I wanted to share it here.

This is not the place for discussion of how complicated CF hotfixes are. That's been discussed to death in many places. If you didn't know, Adobe is indeed addressing the problem in the next release, currently code-named Zeus. You can read about this and 50 other currently publcized Zeus features in a talk I did. And note that they have said they will be back-porting some of that to earlier releases.

Hope it's helpful to someone. If you may have a different experience or opinion about the order of applying security hotfixes, feel free to share it.

PS I have written previously about easy mistakes you can make in applying any CF hotfixes, and how to avoid them. See CF911: Are you finding CF (or CF Admin) busted after applying a hotfix? Three possible reasons. I have also written about the challenges of trying to "skip" cumulative hotfixes. You may want to read them if you've not yet done so.

But again, please hold off on any comments about the complications of CF hotfixes. There's nothing more to do than deal with the situation as it is and await Adobe offering a better solution.

The good news is that the problem can be solved using the simple LOCALURL attribute. The bad news is that you have to do it at all, and that if you don't do it, it can have such unfortunate and unexpected impact. (And just as bad, again, is that hardly anyone has talked about it.) This entry will elaborate on the issue (and a couple of other possible CFDocument performance issues, as a bonus.)

I've been meaning to write about the importance of this problem and solution (the LocalURL attribute) for a long time (it came out in CF8). Often when I'm helping people with CF troubleshooting problems, whether on mailing lists or in my consulting services, I've been able to show that long-running requests (or an unexpectedly excessive number of requests) were sometimes due to this very problem.

Basics of the LocalURL attribute

Before we go any further, let's start with the details of the attribute (which may surprise many). The following is extracted from a larger blog entry about various CFDocument improvements in CF8 from Adobe Engineer, Rupesh Kumar, back in 2007:

When CFDocument body contains a relative URL, ColdFusion will resolve the relative URL to an absolute URL and will send an HTTP request for this url [emphasis, mine]. A side effect of this is Server ends up sending HTTP request even for local URL or images that are lying on the local file system which obviously hurts the performance. In ColdFusion 8, we have added a new attribute "localURL" to cfdocument tag which if enabled, will try to resolve the relative URLs as file on the local machine.

• localURL : "true" | "false" It should be enabled if the images used in cfdocument body are on the local machine. This would make the cfdocument engine retrieve the images directly from the file system rather then asking the server for it over http

This attribute helps reducing the load from the server so that the same web server thread can now serve user request instead of serving local images to CFDocument. This also addresses some of the "missing image" problems which I mentioned here. Here is a sample code using this attribute.

<cfdocument format="PDF" localUrl="true">
<table>
<tr>
<td>bird</td>
<td><image src="images/bird.jpg"></td>
</tr>
<tr>
<td>Rose</td>
<td><image src="images/rose.jpg"></td>
</tr>
</table>
</cfdocument>

So why is this an issue?

It would help to make a point of clarification: CFDOCUMENT builds a document (perhaps a PDF or Word doc) on the server, from whatever CFML and/or HTML is within the tags.

As such, CF will need to "get" whatever images (or scripts or css files) are defined on the generated HTML page (as img src, script src, link href, etc.) so it can build the resulting "document" file on the server.

And the point of the dilemma (identified on this page) is that a single CFDOCUMENT with many such img src (or similar) tags will not just cause CF to look to the file system to get the files they point to. Instead, CF will get them via CFHTTP.

Technically, the issue is that CF doesn't necessarily "know" that the location pointed to in the img src and similar tags *is* on the local server. So it presumes it has to get ANY of them using a CFHTTP call. That's what causes the problem, if there are many of them. Using the LOCALURL attribute tells CF instead that it SHOULD look for the files on the local filesystem and NOT do a CFHTTP to get them.

Sadly, this issue is only barely mentioned in the CF Docs age on CFDocument, and it would be easy to miss the point it's trying to make. (It says only that CF "requests the server for images over HTTP even though the image files are stored locally".)

How some tried to workaround the problem with file:// references

While looking around to see who else maybe had talked about this fix (which, as I noted, I found virtually no other references to it), I did find that some people had effectively "solved" the problem by telling CF to use "file:///" protocol references in the img src and similar tags.

Among the entries discussing this were:

• Including Images in a PDF created in CFDOCUMENT
• CFDocument performance
• You CAN Use the File System With Cfdocument (Who Knew)

It's understandable that people figured it out as a work-around, and perhaps someone even started sharing the idea before CF8 added this attribute, but the LOCALURL would seem generally the way to go.

Some other CFDOCUMENT performance resources

Though not related to the LocalURL attribute, there are some other things that may lead to performance problems.

First, those on CF Standard (as opposed to Enterprise or Developer edition) should know that CFDocument is one of several tags that are single-threaded through CF's "Enterprise Feature Router" (EFR).

Second, there are certainly still other possible CFDocument performance issues, and the following other resources address some of those:

• Cfdocument and Performance, from Mark Kruger
• Images and CFDocument performance, also by Rupesh Kumar
• A workaround for cfdocument missing images, by Rupesh Kumar
• Missing images in CFDocument, by Rupesh Kumar

Hope any or all of the info above may be helpful to some readers. Let me know what you think.

Both CF 9.0 and 9.01 run on older JVMs (and therefore need this update). And are you on CF8? You're not left out: Adobe even has confirmed this update can be applied to CF 8 and 8.01, too!

Update: Since posting this note some have kindly pointed out that Java has been updated beyond update 24, and indeed to Java 7. I did realize that, but didn't mention it simply because u24 is all that Adobe has (for now) certified CF to support. Still, for the sake of completeness, I want to clarify this now and I'll address it more in the final section below.

Old news, but not everyone knows

Someone mentioned today on a list that they'd seen news from Oracle of this important bug (and fix) for the JVM, which can cause someone to crash the JVM using a particular URL string. He also noted that while Oracle had released the fix some months ago, he lamented that "This issue doesn't seem to have gotten too much interest from Adobe."

I explained that in fact Adobe had addressed it, also some months ago.

Adobe's response

Adobe offered a technote on the issue in March 2011.

In fact, they not only confirmed support for (and recommended updating to) the fixed JVM version, 1.6.0_24, but they even (for the first time in years) approved updating to this JVM version for CF 8 and 8.01. Since those ran on very old JVM releases, which had problems not fixed until JVM update 10, this was really good news.

But as his note conveys, word just had not gotten out as much as it could. Beside his thread on that list, I hope now that this blog entry will help reach more people.

More about the bug

If you want to know more about the bug from a CF perspective, check out this blog entry (from several months ago by David Stockton, of cfconsultant.com). He explains the problem/risk as well as shows how to cause the problem (to confirm when it's fixed), as well as some useful extra info on using FusionReactor to help diagnose it.

How to update the JVM for CF

So if you're now persuaded, you may wonder how you go about updating the JVM. You may fear it's like doing open-heart surgery. It's more like getting a mole removed. :-) It could go wrong, but will barely be noticeable if done right.

There are many blog entries that walk through the few simple steps. Find out more from Ryan Stille, Mark Kruger, and Adobe, to name just a few.

While it's not too hard to do, there are just a couple of potential gotchas: be sure to get the JDK not the JRE, and pay attention to the special path format that's needed when pointing to the JVM on Windows.

So if you're on CF and have not yet updated the JVM, seriously consider it.

What about updates beyond u24?

I did realize that, and do appreciate their wanting to share the info. I'd not mentioned updates beyond 24 simply because I would not propose (myself) that anyone now update beyond the release for which Adobe has certified CF. (At least not until compelling reasons arise and substantial community testing suggests it may be safe, as happened with CF8 and the u10 update. Even then, you are risking being out of bounds for support by Adobe, so should make such a change with caution.)

The whole point of this entry was that u24 HAD in fact received Adobe's blessing, for CF 8 and 9, which was pretty compelling and seemed to have been missed by some when it happened earlier in the year.

Anyway, one more tip: in case anyone may find it hard to locate the older updates (like u24) on the Oracle site, here is a link (which works, at least, for now):

http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase6-419409.html

Again, be sure to get the JDK (development kit) not the JRE (runtime environment) among the options listed there.

My session will be "CF911 ColdFusion Performance Report 2011", a new talk/concept I've created. Here's the description:

Starting a new tradition, veteran CF troubleshooter Charlie Arehart will present a review of the performance aspects of making various choices when working with ColdFusion, especially in recent version(s) of ColdFusion. Leveraging the important value of real load testing (as opposed to the less accurate conclusions from "large loop" testing), Charlie's annual report will help attendees appreciate the performance-related improvements of new/changed features, as well some older features where choices can make an important impact. Depending on the timing of the release of "CF next", the session may cover its new features, but it will certainly cover some things new in CF 9 and 9.0.1.

As I note there, I hope this may become an annual event which I might present at this and/or other conferences. (It's an idea rooted in a similar presentation made by a former colleague, from my first IT career from 1982-1997, where he presented the annual "Jim Damon model 204 Performance Report".)

About RIACon

As for RIAcon, I hope you're considering it. Phil Nacelli and the folks at AboutWeb have been working hard to put together the conference, which in some minds is kind of picking up where CFUnited left off. It will be a more intimate event, much like CFunited was when it first started.

Indeed, some will recognize that the location for RIAcon is across the street from one of the hotels where CFunited was held in its early years, right next to the Twinbrook Metro station in Rockville, MD.

A Personal Connection to the Hotel Location

Even more of a delight for me personally is that the hotel (The Legacy Hotel) is right on the land that was once the location of Congressional Roller Skating Rink (until the late 70's), where my sister and I (and many friends) spent our teen years pretty much whenever we weren't in school. Yep, I was a skating nerd: dance, figures, freestyle, and more. Here's incriminating evidence!

The challenge

I helped them determine ultimately that the problem was not CF at all, but instead something amiss in their web server, in this case Apache. (Before any Apache defenders come at me, please: I'm not "hatin' on Apache", just reporting what we observed. Do keep reading for more details.)

I asked if they'd considered at least trying IIS to confirm if it might work better for this challenge, but they preferred the file-based configurability of Apache. While I noted that IIS had gotten better in recent years in that regard, they preferred to bring in some experienced Apache guys to sort things out. (I don't claim any particular expertise with Apache, and I'm not at all averse to letting a customer know when they may need to have someone else help with certain problems.)

The customer's first attempt at resolution

The Apache consultants identified some configuration changes which they asserted were undocumented, but felt were required to get past an issue happening on this Windows 2008 R2 setup:

• UseCanonicalName - needs to be on
• httpd-mpm.conf - needs to be included in apache config
• EnableMMAP - needs to be off
• EnableSendfile - needs to be off

I'm not verifying or confirming the validity of these suggestions, just reporting what the customer was told, if it may help anyone.

Anyway, it worked for a brief while, but the problem soon hit my customer again. (If any Apache folks want to offer any thoughts based on this limited info, feel free. Again, I'm not writing this to knock Apache.)

The customer's reconsideration of my suggestion

At that point they recalled my suggestion a few days before about at least giving IIS7 a try.

They reported their success with that:

"We read up on IIS installation and had things and running in about 45 minutes, and it was screaming. We moved all of our servers to IIS over the next few days. You were so right, IIS7 is a great piece of software and is super fast!

I really thought that getting the rewrites and redirect stuff set up would be a pain, but it wasn't. Even though I prefer a config file for portability and archive purposes, I do like the gui.

So, thanks for everything: keeping us from second guessing our application and for putting the IIS bug in our ear!"

Just in a day's work, my good man. :-)

Seriously, though often I do help people find and resolve problems within CF (more often in configuration than in code), I do also occasionally help demonstrate that a problem is not related to CF at all. It instead is a victim. And indeed, in many environments, it's the "red-headed step child" who gets blamed for everything first.

Let me know if I can help you

So if you may ever need help trying to understand and resolve a problem of CF performance, let me help. My goal is to work fast, generally on-demand, and to not only help solve the problem but to help educate you so you can better understand the available diagnostics, and connect the dots, so as to be able to solve such problems yourself in the future.

And as in this case, sometimes the assistance simply helps get the monkey off your (or CF's) back and into someone else's lap, when we can demonstrate that clearly.

If you may be interested in seeing some other customer reference stories, check out a page with some of them.

Here are the details.

First are the two talks:

• Pinpointing and Resolving ColdFusion Performance Issues (see the link for details on the topic)
• More Hidden Gems in CFBuilder and CFBuilder 2 (see the link for details on the topic)

(I had put in just the first talk originally, and then a few weeks ago a slot opened and they asked if I could do the other, which I was happy to offer, as an reprisal/update to my talk from the first release.)

Then for the Lightning Round (or what was originally referred to as the Pecha Kucha), my talk will be:

• Lies, damned lies, and CF request timeouts (in which I'll share in 5 minutes some information that even experienced developers admit having never known)

Finally, for the Birds of a Feather (no page on their site listing them yet), the session I will be leading will be:

• CF911: Share your CF server troubleshooting tips (come share some ideas, or learn from myself and others)

Sense a theme? Yep, other than the CFBuilder talk, the other sessions are all focused on the topic that is now most near and dear to my heart (and livelihood): CF Server Troubleshooting. It's what I do, and more important it's how I feel I can best help the most people.

There's one last aspect of my involvement at the conference that I'll mention: they started a new sponsorship program this year called "Friends of cf.Objective()", and I'll be participating in that. No mention of it yet on their site, but there should be more news at the event.

So hope to see you there, or if you won't be there, I'll post if any of these are recorded, or if not then I would likely record them myself in the future.

What's changed about IIS 7 support in 9.01?

Some folks will know that ColdFusion 9 Updater 1 (9.0.1) has finally added full support for IIS 7, without need to rely upon enabling IIS 6 Compatibility (which IS still required for CF 9.0, 8.0, and 8.0.1). This is indeed great news, whether you're running on Vista, Windows 7, or Windows Server 2008, which all have IIS 7 by default, and for which you can enable IIS 6 Compatibility mode, but it's not on by default and not always straightforward to enable.

So bottom line, if you're on 9.0.1, you no longer need to go through the hoops described in the CF9 Admin/Install docs (nor in helpful blog entries like here and here, though those are still great for those running on CF 9.0 and 8, and may even offer tips of value to anyone setting up CF to run on IIS, which has other challenges on Server 2008.)

Gotcha 1: The IIS 7 Compatibility change is NOT documented where expected

Sadly, though, if you go looking for help on this in the CF docs, such as Chapter 6 of the manual, Installing ColdFusion 9, you will find that it has NOT been updated with the info that is new in the updater.

It opens, "If you are configuring IIS 7 ... ensure that you have the options IIS Metabase and IIS 6 configuration compatibility ... and ISAPI Extensions ... selected".

What a shame.

Solution 1: Where the change IS documented

So with respect to change in 9.0.1, where you no longer need to enable IIS 6 compatibility, the details are covered instead in the installation guide that was created just for installing CF9 updater 1 itself, called "Installing the Coldfusion 9 Update", available online at:

http://www.adobe.com/support/documentation/en/coldfusion/901/cf901install.pdf

It's certainly reasonable to expect that the primary install manual would have been updated with the info above.

But that's why I'm pointing this out. I have also added a comment explaining it on the page pointed to in the first link above. Hope that may help someone.

(The same info is also offered as a chapter in the manual, "ColdFusion 9 Updater 1: New Feature Notes", available at http://www.adobe.com/support/documentation/en/coldfusion/901/cf901features.pdf, which is of course very interesting if you may have missed it.)

I'll explain the second gotcha in a follow-up blog entry.

I'll detail the limits per version/edition below.

I'll also offer a (possibly surprising) workaround that can allow you to get even more requests through IIS, even for a single web site.

(Before I elaborate on that, note that there is a separate issue if you're finding that CF doesn't let you see more than 25 requests at once. That's instead due to a setting in CF/JRun, the maxworkerthreads setting. For more on that, see this blog entry.)

That said, this is a problem which could affect anyone regardless of the app server they may be running behind IIS. (And yes, I do realize that for some, the answer to this problem will be, "see, that's another reason to run Apache." We get that. Let's just focus on this problem for those who choose/have to remain on IIS.)

Background

I was doing some load testing noticed that I couldn't get beyond 3 requests running at a time. I suspected the problem may be IIS.

So at first I tried just making the same requests against CF's built-in web server (such as might be running at port 8500, which can be enabled/configured during CF installation or manually).

Sure enough, CF could execute more requests at once (up to the "simultaneous requests" setting) through the built-in web server.

So that told me the problem had to be in IIS. I did some digging and found the documentation that affirmed what I was seeing.

(Some may recall there used to be a limit of 10 for IIS on Windows XP, so it may surprise some to run into an even lower limit on later Windows versions.)

IIS 7 does have a "request execution limit"

The first resource I found was with respect to the limits in Vista. This page says specifically: "With Starter and Home Basic editions of Windows Vista, the simultaneous request execution limit for IIS is three for Windows Vista Home Premium. ...For Windows Vista Business, Enterprise, and Ultimate edition...the simultaneous request execution limit is ten. ..With server editions of Window, IIS 7.0 has no request execution limit."

But I'm sure some reading this will be using Windows 2008. I found a page discussing its limits: for the Basic & Starter editions: 3 requests, for Premium: 3, for Pro: 10, and for Server: unlimited.

I happened to be running Windows 7 when I hit the limit, and while I've not found a document stating the limits specifically for Windows 7, I can again confirm the same limit of 3 on my copy of Windows 7 Home Premium, so I'm sure things are the same, to whatever degree the edition names parallel the other versions. (It's curious that the learn.iis.net page above does discuss both Vista and Windows 2008, but makes no mention of Windows 7.)

A workaround for this limit: multiple worker processes

With respect to this limit, here's a valuable bonus tip that I've not seen documented anywhere: the limit is really per application pool, or more technically per worker process. So you can certainly get more request simultaneously against your box by using multiple app pools.

But perhaps you want to have more requests against a single site, which obviously can be connected only to a single app pool. There's still good news: you can increase the number of worker processes per app pool in the "advanced settings" for a given app pool (right-click on the app pool), increasing "Maximum Worker Processes" from the default of 1. (Some will recognize that as being the same as what was known as "web gardens" for app pools in IIS 6.)

For those new to them, whether creating new app pools or more worker processes for an app pool, for each new worker process, you'll see a new w3wp.exe in task manager.

A caution, for those using ASP.NET, about setting more than one worker process per app pool

Finally, there's a caution to consider if you decide to increase the number of worker processes. At least back in IIS 6, I documented that if you're running an ASP.NET app using sessions that are "inproc" (or in memory), the default, there is a problem with using multiple worker processes (web gardens), in that the sessions are not replicated among the worker processes. That may not be an issue for the OP, so I'll say you can learn more at an entry I did a few years ago.

Did any of this help you? Let me know below.

Here's the next, related, myth:

True or False: "If/when I apply Cumulative Hotfixes, I need apply only the latest CHF, right?"

For instance, let's say you're currently running CF 9 update 1 or CF 8.0.1 and discover (perhaps due to my last blog entry) that you had never applied any of their associated CHFs. It would seem you should just be able to apply the latest CHF and not bother with anything related to the previous ones, right?

Answer: Well, yes and no.

There may be manual steps in skipped CHFs

Technically, yes, you need only apply the latest CHF in terms of getting whatever hotfixes are included in the chf jar.

The problem is, there are sometimes multiple steps involved in applying a given CHF (especially in CF 7 and 8), or there may be specific hotfixes that are indicated at the end of the CHF technote as requiring a manual step. I'll explain the differences in more detail in a moment.

If you have NOT done those manual steps, you WILL still need to do them, even if you "skip" that CHF in question.

This is definitely the case for CF 8.0.1, which had 4 CHFs, and also for CF 7.0.2, which had 3, and for each release some of the CHFs had manual steps. It's not the case for CF 9 Updater 1 (9.0.1) CHF2 and 1 (this sentence added as an update since this entry was originally posted.)

The table below details which CHFs, specifically, have manual steps. (For CF 8.0, none of the 3 CHFs had any manual steps. I'll explain later here why I can't tell you for CF 7.0.1 or 7.0, and why this isn't an issue for CF 6.1 and 6.0 users because they didn't have CHFs at all to potentially "skip".)

This isn't a mere technicality: it could be critical

Some may think I'm being pedantic in raising this concern, but take my word as a CF troubleshooting consultant: some of these manual steps are very important ones, so it's really unfortunate that some people may be "skipping" them inadvertently. I help people with this very problem at least once a month.

For instance, in 8.0.1 CHF 4, there are both a bootstrap.jr needed, some manual hotfixes, and some related to security fixes. In 8.0.1 CH 3 there are important fixes related to image processing problems (which have plagued many, who are missing this fix).

And perhaps most important, for those running CF 7.0.2, there was a surprisingly critical (yet innocuous looking) manual step in its CHF 2, and this one hotfix may be the explanation for many people suffering inexplicable memory leaks in that release. I'll discuss each of these more in a moment.

What do I mean by "manual steps" in a CHF? How would you tell if they are there?

What I'm talking about here is either of different kinds of manual steps in a given CHF. I'll first explain them, then reflect it more succinctly in a table to follow.

1: A simple, single-step CHF

First, by comparison, note that for most CHFs, applying the update merely involves downloading a zip, extracting a single jar, and using that to apply the update (whether by uploading it in the CF Admin "system information" screen, or by dropping it into the appropriate lib/updates directory, each of which are discussed in the technotes. I'll note that many don't realize they can apply HFs and CHFs merely by dropping their respective jar into the appropriate lib/updates directory: the technotes sometimes only mention this fact in the "uninstalling" section, where they point out that the files to be deleted have been placed there by using the Admin interface.)

2: A multi-step CHF

As a second example, in contrast to the simple one-step CHF above, sometimes the technote for a CHF will have more steps which indicate that you need to manipulate multiple files in one or more extra steps.

As I mentioned above, the CHF4 for 8.0.1 is an example of that. This is the kind that is most disconcerting to me.

3: A CHF with multiple zips

A third example is really a variation of the last one: some CHFs don't have so much "multiple steps" but instead have multiple zip files that need to be extracted.

The CHF1 for CF 9.0.1 is such an example. Note that its steps 6-9 involve updating files in WEB-INF/cftags and CFIDE directories.

In such a case, we just need to hope that any next CHF will offer those same files (and as an update since this entry was first written, CHF2 DOES include the same--though perhaps updated--files in its zips).

Unfortunately, the technote for CHF2 doesn't make this entirely clear, but I compared the extracted zips to confirm it.

4: A CHF with separately applied individual hotfixes

Finally, in some CHFs, there may still be only one chf jar file, but after the simple list of steps for applying that, the technote may then also list additional individual hotfixes which still need to be applied, separately from the hotfix.

These may be listed either at the top or bottom of the CHF technote (though usually, they are listed at the bottom). There are several CHFs of this sort, and again I will detail them for you later here. But first, let me stress an important example of this.

A Critical example from CF 7.0.2

A critical (and sadly, oft-missed) example of this is the 7.0.2 CHF 2. At the bottom of that page are listed several such "manual" hotfixes, and among those is one extremely important one. Unfortunately, the wording on the page doesn't make it sound very worrisome (and frankly, seems incorrect from my experience). In testing I did at the time, this was a hotfix which when implemented would stop a bug where CF would hold memory from a file upload until CF was restarted--a true memory leak. Adobe did fix the problem in CF 8, and said so, which is how some of us became aware of it.

But even if you DID read the CHF technote, you may not sense the severity. The link to the hotfix labels it as "Update for cffile memory leak", and the text preceding that says, "This hot fix is for a potential memory leak caused by cancelling cfuploads in progress with ColdFusion MX 7." In my testing, though, it really had nothing to do with "cancelling cfuploads". It was any file upload (where you had an input type="file" in a form that was used to post a file) to a CF page, whether you cancelled it or not!

Further, if you go on to read the page about the hotfix itself, its own title might lead some to think it applies even less to them, "Hot fix to make ColdFusion release memory properly with file uploads and CFC's stored in application, session or server scope". Is this meant to be read that the file upload has to happen in a CFC stored in a shared scope? If you thought so, again, you may shrug it off as a seemingly rare situation, but again in my testing back then, it did not matter. Any file upload to a CF page held memory for the size of the file uploaded, until CF was restarted. To make matters worse, the text in the body of the technote says (in my mind, incorrectly), "ColdFusion does not release the memory properly with file uploads when a reference to a CFC is stored in the application, session or server scope in the same page".

Take my advice: ignore all that mumbo-jumbo. If you're still on CF 7.0.2 and you missed that manual hotfix listed in CHF 2, go apply it! It may be the reason you've had CF crashing for running out of heap. (And if you're still on CF 7, then of course you should move up to the free 7.0.2 updater. Again, I discuss and link to updaters in the previous blog entry.)

Again, though, this is just one example (7.0.2). There are similar examples of such similarly-required separate individual hotfixes in some other CHFs for other releases.

When will adobe stop the madness with an automated installer?

Well, the good news is that as Adobe has been talking about the upcoming new release (currently codenamed "Zeus"), one of the most significant new features is an automated hotfix mechanism. This isn't the place to elaborate on that (since few details have been shared), but I may do another blog entry in the future, if someone else doesn't first. (If you're reading this and know somehow who has, share it in a comment.)

What CHFs in what releases have manual steps?

So, given all the above, which CHFs do you need to worry about, if you are intending to "skip" them? To help make things easier to track, following is a table that identifies each CHF for the most recent releases, and it indicates for each CHF whether it has any manual steps. If it does, then if you are skipping it to move to a later one, you need to be sure to apply those manual steps:

So you can see that this problem is most significant (for now) for those on CF 7.0.2 and 8.0.1.

I'm not going to list 7.0 or 7.0.1, because for one thing, the links to the technotes for their CHFs are currently failing for me (as offered from the CF 7 hotfixes page), so I can't look at them to confirm if they have manual steps. It's reasonable to assume they do. Another reason not to list 7.0 and 7.0.1 is that, again, if you're on those releases, you really ought to update to 7.02 (for free), if not to 8 or 9.

You may notice that I don't list CF 6.1 or 6, either. Well, in fact, the whole concept of cumulative hotfixes was added only as of CF 7, so this concern (about trying to "skip" CHFs) just doesn't apply to those running CF 6 or 6.1.

And don't forget to check for any subsequent hotfixes after whatever "latest" CHF you apply

Finally, this entry has focused on what manual steps you may need to do related to previous CHFs you may be trying to "skip". But separate from those, keep in mind as well that there may be one or more individual hotfixes that have come out since any given CHF was released (or you may have applied it).

Part of the challenge is that, since the technote for a given CHF is written when that CHF is released, it obviously does not at that point in time reflect any new hotfixes posted after that. I suppose we could argue that Adobe should warn you (at the bottom of each CHF) to also go check if there are any subsequently released hotfixes.

For now, it's incumbent upon you to keep an eye on the hotfix page for the version you are using. I listed them in the last blog entry, but here they are again:

• "ColdFusion 9 : List of Hot fixes" (for 9.0 and 9.0.1)
• "Hot Fixes | Cold Fusion 8 and 8.0.1"
• "ColdFusion hot fixes (MX 7 through MX 7.02)"
• "ColdFusion Hot Fixes (MX through MX 6.1)"

For example, as of this writing, there are 2 hotfixes listed after (chronologically) the latest CHF for CF 9, CHF 1. There are also 2 hotfixes currently listed after the latest CHF for CF 8.0.1 (CHF 4), there are 4 hotfixes after the latest CHF for CF 8.0 (CHF 3), and there are 2 after the latest CHF for CF 7.0.2 (CHF 3). So again, if you think you're "at the latest CHF", make sure there may not be still more hotfixes that apply to you. For more information, see the corresponding page in the links immediately above, for whatever version of CF you're running.

Finally, with respect to watching out for individual hotfixes within a given release, note that you generally cannot watch only the main "CF Updates" page. That generally lists only installers, updaters, and CHFs. (That said, there is at least one "input sanitization" hotfix shown at the top of the list of CF 8.0.1 CHFs. )

Hope all that's helpful. Let me know what you think.

First myth up for consideration:

True or false: "If/when I download CF to install it from scratch, the installer has all the latest fixes (updaters, at least)"

Answer: False (generally). For instance, if you download CF9 today (Dec 2010), you still get CF 9.0, released originally in Oct 2009. You don't get the latest updater (9.0.1 as of this writing, released July 2010), though its existence is at least mentioned on the page, nor of course does it then include any hotfixes or cumulative hotfixes.

Why not, you may wonder? I'll explain more in a moment, along with more about hotfixes and updaters as concepts (and where to find them specifically, for each CF release).

About this CFMyths Series

First, I want to introduce this new series, CFMyths. Today's entry, though prompted by a question on a mailing list, is in fact a frequent source of confusion for folks. Indeed, it's one that I've covered (along with many like it) in a CFMythbusters talk that I've given at various events. Of course, relatively few see such talks, and even though I offer the details in the slides, available on my site, many never dig into those, either I think, so I've long meant to create some blog entries from them.

Today's question prompted me to go ahead and start that series. (And I know I still owe readers the continuation of a CF911 series on memory problems that I started last month. Part 2 is now written. I just needs to refine it. This topic got my attention, and once I started writing, well, here you go. :-)

"So why is the currently available installer not necessarily 'the very latest version'"?

It's about logistics, really. CF runs on many platforms (OS's, web servers, databases, and different releases of each), so it's expensive for Adobe to create new installers. This is why the base version may be left there for quite a while, with you being expected to apply any subsequent updaters or hotfixes. That will surely surprise many, but it's the way it's been for some time (except 8.0.1, when a completely new installer was offered, in addition to one to update those already on CF 8.)

So it's incumbent upon you, when you download a given release, to pay close attention to what version it is. It will be reflected first in the installer filename, such as coldfusion_9_WWE_win64.exe. It will also be listed with the specific version number as reported in the CF Admin and logs once it's installed (such as 9,0,0,251028 for the base version of 9.0, or 9,0,1,274733 for the base version of 9.0.1). You'll then need to check to see if there may be any updates, hotfixes, or cumulative hotfixes. The same is true for 8.0.1, too (whose base build number is 8,0,1,195765). I'll point you to the updaters and hotfixes in a moment.

"What are all these terms? Hotfixes, updaters, CHFs?"

Before proceeding, it may help some readers if I explain the terminology of the various updates for CF that may exist:

• Hotfixes are individual fixes to specific problems (typically offered as a single jar file, such as hf801-76563.jar, and for which there is usually an individual technote, such as this one for that hotfix, which is a recent fix--Oct 2010--for CF 8.0.1)
• Cumulative hot fixes (CHFs): when there have been many hotfixes, they will typically be rolled into a cumulative hotfix which includes several(such as the CHF 1 for 9.0.1, which can only be applied to CF 9.0.1, not CF9). There's no fixed number of hotfixes which will trigger Adobe to create a CHF. They are usually deployed also as a single jar, and you are expected to remove any individual hotfixes that are included. Again, the technote for each hotfix will explain these things. As the name implies, they are also cumulative, such that CHF 2 includes all the hotfixes that CHF1 included (with a caveat, discussed below). CHFs do not included new features
• Updaters: When there have been some number of CHFs, they will often be rolled into an update/updater (like 9.0.1, 8.0.1, 7.0.2, 7.0.1, 6.1). Updaters are always executable installers, and they often do add some minor new functionality to CF.

Adobe has a page that explains more about these terms generically.

Note that when looking at hotfix/CHF filenames(such as hf801-76563.jar), you can tell by its prefix whether it's a hotfix (hf) or CHF and what version it's for (8.0.1, in that example.)

Indeed, that brings up another potential gotcha: be careful about inadvertently applying a hotfix/CHF to the wrong release, or leaving an old HF in that's been obviated by a CHF that includes it. I discuss the potential gotcha of applying the wrong hotfix/CHF for the wrong version in a blog entry, You may have mistakenly applied an 8.0 CHF on a 8.0.1 CF server, and not realize it!

Finally, the Adobe technote page about each hotfix, CHF, or updater will each explain how to apply that particular update. Again, I'll offer links to the key pages for different release updates in a moment. First, there are a couple of other common misconceptions I want to address.

Phew: I bet some readers thought all this should be pretty straightforward, and may be surprised to learn all these details. It's the kind of thing I often find myself helping my customers correct, and again it also often comes up in questions on lists/forums. You might think we've covered all there is, but sadly, there are still some more gotchas.

"At least when I apply an updater, that includes all hotfixes that preceded it, right?"

Well, not necessarily. For instance, when the CF 7 updater 2 (7.0.2) came out, Macromedia decided not to bundle an updated set of JDBC drivers in the updater. It was up to you to download and install those as a manual hotfix. I blogged about that back at the time, in 2006.

Again, the logic was understandable: there were considerable changes introduced by the drivers (licensed from a third party), and forcing it on existing users could have been troublesome. If you wanted the updated drivers, you needed to download (for free, from Adobe) and install them yourself. The installer notes clarified this, so as always, it pays to read the updater documentation carefully. There are often multiple documents for any new updater, including a FAQ, release notes, and more.

"Well, at least with Cumulative Hotfixes, I need apply only the latest, right?"

Again sadly, no, not necessarily. Let's say you're on CF 8.0.1 and never applied any of its 4 CHFs. You may think you can just apply CHF 4 and not bother with anything related to the previous three. Unfortunately, there are often manual steps within any one previous CHFs which you WOULD still need to apply.

In fact, this question (and answer) is important enough that I'll create another entry on that so it's not lost here (where this entry's title will lead some to think it applies only to installing CF from scratch).

"OK, so where do I find these updaters I need to check?"

Fortunately, there's one primary page you can keep an eye on, but technically there are various pages you may want to check, depending on your CF version, to get more or less detail.

First, the main "CF updates" page can be found here. It not only includes updaters and CHFs, it even has them for CF 9, 8, 7, 6, and even 5, as well as CF Builder (and CF Studio!)

For those on CF 9.0.1, it includes the latest CHF1 for CF 9.0.1.

Note that it also lists CHFs for CF 8.0.1, 8.0, and 7.0.2.

As for updaters, it includes those for 9.0.1, 8.0.1, 7.0.2, 7.0.1, 6.1, and so on. (Sadly, there's no HTML anchor within the page for sections like the 9.0.1 updater, so I can't offer a link to that part of the page. But if you're still running CF 9.0, go get it! It includes useful new features.)

As for getting a list of all the individual hotfixes (and CHFs) for any specific releases, there are individual pages for those:

• "ColdFusion 9 : List of Hot fixes"
• "Hot Fixes | Cold Fusion 8 and 8.0.1"
• "ColdFusion hot fixes (MX 7 through MX 7.02)"
• "ColdFusion Hot Fixes (MX through MX 6.1)"

While these list both hotfixes and CHFs, the info on the CHFs should be the same as the main "CF updates" page offered previously. But note that these version-specific update pages may well list new hotfixes that came out after a CHF. Do keep an eye on them.

(You may wish there was a better way to keep up with updates and hotfixes, whether a feed you could follow, or even an automated update mechanism. Sadly, there have been feeds but I'm not aware that is reliably updated by Adobe. And there is no automated update mechanism for CF from Adobe. But there is a free tool and service that solves both those problems, providing an automated update mechanism and constantly updated feed of hotfix notifications. For more information, see Merlin Manager.)

Finally, again, look for another entry to come on the sticky problem of how you can't "just apply the latest CHF" and assume you're good to go on any previous updates for that release. Sadly, it's just not often the case.