BTW, today is "more about the CF Server Monitor" day today here at carehart.org. :-) In my last two entries today, I talked about related matters, regarding the impact of the 3 "start" buttons (monitoring, profiling, and memory tracking), as a followup to an older entry I did on them when the monitor came out with CF 8 in 2007. See the "related blog entries" below for more.

In the last entry, I mentioned that in 9.0.1, Adobe added a new "Monitoring Settings" page to the CF Admin, and one of the features is that ability I discussed to turn off the 3 start buttons from within the Admin.

Below that is this other feature, labeled "Enable Monitoring Server". Let me say first that has really have nothing to do with all the discussion of the "start" buttons in the previous entries.

So what does "Enabling Monitor Server" do?

All it really does (if enabled) is start a new web server (within CF) that the Server Monitor client will then use to talk to CF. That's it.

All the CF Server Monitoring activity (gathering the stats, etc.) is still done WITHIN CF itself, as it always has been (as controlled by those 3 "start" buttons discussed above). As I've explained before, the CF Server Monitor is just an interface to view that information--regardless of the web server port.

Indeed, it bears noting that if you use the "built-in web server" (offered during installation or enabled manually), so that you access the CF Admin on, for instance port 8500, then you are already accessing the CF admin from a different web server than your production traffic, assuming that's coming in via port 80 (such as from IIS or Apache).

But some people may well not enable that built-in web server, and they may access the CF Admin via the same external web server as all the other traffic. Well, if something has made CF not able to respond to all your other traffic, you may find that the CF Server Monitor also cannot respond.

So this is a 3rd, special, web server option for CF

Enter this new (yes, third) alternative web server: if enabled, then the CF Server Monitor will talk to it (on port 5500 by default).

And whereas enabling the traditional "built-in web server" involves editing XML files and restarting CF, this new CF 9.0.1 option is just a single click and it takes effect immediately. No restart required.

If you click the "server monitor" button from within the "Server Monitor" page in the CF Admin after enabling this, you'll see that it opens the monitor to that port 5500 (or whatever you tell it to use.)

FWIW, this new web server does indeed start up *within the CF memory space*, but it's very lightweight. Still, this further diminishes the mistaken assertion that somehow this feature makes the "monitor run out of process".

All that said, it's certainly a good idea to use it, of course. I just wanted to clarify what it really is, and is not, since I so often hear people still assert otherwise. I don't blame them. There's not much documentation on it, and some Adobe folks did in fact at early CF 9.0.1 launch presentations suggest this mistaken assertion. I had been a little reluctant to call it out, hoping it may have gone away, but since I still hear it, I felt compelled to go ahead and write.

Reminder of what the CF Server Monitor is, and that it is always "in process"

Again, as I've talked about previously, the CF Server Monitor is an interface to data collected within the CF instance itself. It doesn't matter what web server you use to launch the monitor. It's still going to talk (via Flash Remoting) to the CF instance to get the data that it shows you.

And yes, if CF goes down, the CF Server Monitor goes down with it. It is always an "in process" monitor (as are also FusionReactor and SeeFusion in their basic configurations.)

What if you do want to watch CF from "outside the process"?

If you want something that watches the CF instance "from the outside", that's indeed reasonable. You may want something that helps you see when one or more CF instances (perhaps on multiple machines) is acting up (or going down). That's available as another tool, separate from the CF Server monitor, called the Multiserver Monitor. IT's also a feature available in FusionReactor and SeeFusion. Indeed, it's a topic worthy of its own entry. Coming next.

Hope this was helpful to someone. I always look forward to feedback.

The "good" news is that there are at least two really common explanations of what may have happened, which I'll explain them here. Once you consider them, you may find either that you can confirm this is what happened (and fix it), or if nothing else you can keep it in mind if you're ever applying them yourself in the future.

For some of the hotfixes in particular, among the errors people may get related to this are several related to the ESAPIUtils class: "Element ESAPIUTILS is undefined in a Java object", "Could not initialize class coldfusion.security.ESAPIUtils", "Class not found: coldfusion.security.ESAPIUtils", and so on.

But even if you're not getting these particular errors, the info here should help. Honestly, I feel it's required reading for anyone applying any CF hotfixes, since the mistakes are so easy to make.

I help people solve this very problem often, whether on CF mailing lists or in my independent consulting as a CF troubleshooter. And I've been meaning to post these thoughts for months but as you'll see below, there's a fair bit to consider, if you look beyond what one may try to communicate in a tweet or simple mailing list answer. After doing just that today on yet another forum, I decided to offer the expanded explanation, and hope that it may help someone.

First, some background.

What's different about recent CHFs, SHFs, and HFs (past couple of years)

Before addressing the problem, it would help to understand what's different about hotfixes (for 8 and 9) the past couple of years which can make this an issue in the first place.

It used to be that most hotfixes (CHF, SHF, HF) were just a single jar file, that you would (per the technote for the hotfix) just either upload using the CF admin "system information" page or drop into the appropriate \lib\updates folder.

But in recent years, the hotfixes have gotten more complicated (solving important security problems, often), including now often needing to update entire directories, whether in the WEB-INF or the CFIDE (where both the CF Admin and also various UI features for CFML are stored).

Well, if you make a mistake in doing that (updating those directories, or doing it in the wrong place), then you may find that some part of CF is busted, whether the Admin or perhaps even part of your app (which relies on finding those properly updated files within the CFIDE directory).

Let me make one important note before, some jump in here to (reasonably) bemoan the situation.

Note that Adobe is addressing this with the next version of CF

Yes, it is unfortunate that these problems can happen. And the good news is that Adobe is addressing it in the next release of CF. They have pointed out in a number of recent public presentations and blog entries that they will be adding an automated hotfix mechanism in the next release, for now code-named Zeus.

Also, at the 2011 RIACon conference, during the Adobe keynote, it was indicated that they planned to offer a form of this hotfix installer for CF 8, 8.0.1, 9, and 9.0.1 as well.

But until then, the following may prove helpful.

Now, back to the problem at hand: how you may make mistakes in applying hotfixes that may leave things busted. My observation (in helping lots of people with this problem) is that the challenge is primarily three-fold.

Challenge 1: Updating the wrong directory CFIDE

The first problem could be that you have installed hotfixes related to CFIDE into the wrong place. It's surprisingly easy.

I noted earlier that often the hotfixes may now have you update code in the CFIDE directory. Most know that to be where the CF Admin is stored. But it's also where various files are stored (by default, unless you move them) to be used by various UI elements of CF, in CFIDE\scripts. For instance, all the ajaxy things are stored there, as are the older cfform elements. There's also CSS, XSL, and other stuff there. That's why those things can break (silently, since it's the client's browser that now can't find what it wants, or finds the wrong version of a file, based on CF generating code that expects to use the "updated" versions.)

Well, here's the problem: when the technotes tell you to extract the zip into the CFIDE directory, they often leave you to figure out where that should go.

And the problem is that you may have many. For one thing, when you install CF, you're asked if you want to use the built-in web server, or an external one. If you do the former, then the CFIDE is put in the [cf]\wwwroot. if you do the latter, it's stored wherever you tell it is your web server root, whether inetpub\wwwroot, or htdocs, or wherever.

And if you use the Multiserver form of deployment, you may find that even if you install CF initially to integrate with your web server (in which case it would put the CFIDE in perhaps the inetpub\wwwroot, if/when you create new instances, they by default each have their own CFIDE deep within the instance, such as [JRun4]\servers\[instancename]\cfusion.ear\cfusion.war\CFIDE.

So when you run the update, you need to be POSITIVE that you are updating the one that your CF instance is really using, which means you may need to update many.

And if you're not careful, you may actually find you currently have a CFIDE directory in both kinds of places (and more), either because you have had multiple versions of CF installed, or someone has copied the files from one place to another to "fix" a problem. Then also, some admins (and hosting providers) even repeatedly copy the CFIDE (or perhaps just CFIDE/scripts) to the docroot for different web sites, trying to help with some other issues.

The upshot then is that you could easily have more than one CFIDE.

But it gets better: you can also set things up so that you can access the CF Admin either through the built-in web server, or through the external web server, or both. So besides the question of where the CFIDE lives, there is also the matter of where your web server (whichever you're using) is expecting to find the CFIDE.

And this goes for the CFIDE/scripts. Whether an admin has made multiple copies of it, or just manually added a virtual directory definition to their web server, this means that what matters most (for "finding" the CFIDE to update) is where the web server says it's looking.

Now, before someone gets too burdened with these prospects, note that I'm just explaining some of the many things that CAN happen. You may have a simple environment, and only one (or maybe two) places where the CFIDE lives.

So where to look to know where to update the CFIDE?

Given all the above, what are you to do?

Well here's one tip (not mentioned in the technotes): if you look in the CF Admin, you will find in the Mappings page that there is in fact a mapping for where *CF* at least thinks that the CFIDE is located. So first thing before applying the hotfix, check out that mapping, and at least be sure to update THAT location. That may be all you need.

But second (and even despite doing the above), do look at your web server (IIS or Apache), and see where THEY think that the CFIDE is located. Remember, that's what your browser will end up using (whether for the Admin, if you access it via those web servers, or for your end users running apps on your server). The point again is that they may show different CFIDE mappings, either for different sites, or within different sites.

Yes, it's lamentable. But the problem is caused by people doing things on their own that they need to remember they've done. And no, I doubt Adobe really will be able to fully resolve this, since they'd have to go digging in your web server to find the info. (They could, but should they? since they didn't cause the problem?)

And consider too that it may be that the different CFIDEs are leftovers from different CF versions you may have installed, and each may have been installed differently (one using the built-in web server for the CF Admin, one using the external web server).

So as the captain in the old show, "Hill Street Blues", used to say to his patrolmen after their morning briefing, "be careful out there".

Challenge 2: Extracting the zips at the wrong level

This next challenge is different from the above, and yet applies to that step (extracting the zip for the CFIDE). But it also applies to extracting the zip for the WEB-INF, or any other directory where a hotfix says to extract a zip.

Here's the problem: it's possible that even if you point your zip extracting tool (winzip, izarc, winrar, copy/paste, whatever) to the "right" directory, you may mistakenly (or the tool may) extract the zip in such a way that what you extract is not at the level you point to, but one level below it.

I've seen it happen, to myself and others. (And some zip tools are more prone to it than others, especially winrar, in my experience.)

Here's the thing, if the technote says, for instance, to extract from the zip the web-inf directory, if you're not careful you may end up putting a NEW \web-inf under your current one! So you end up with \web-inf\web-inf. That will NOT, of course, update the needed files within the "real" \web-inf directory.

And of course the same could happen when you extract the CFIDE. You could end up with CFIDE\CFIDE.

Indeed, I've seen people have it happen when they extract the jar to the lib\updates.

So again be VERY careful, and double check things as you proceed.

Challenge 3: Be sure to do ALL the steps in the technote

Finally, another mistake I've seen people make is that they miss one or more steps in the technote. Again, these recent hotfixes have gotten more and more complicated, and have many steps.

Again, the automated hotfix mechanism in Zeus should address that.

But until then, it's incumbent upon you to make sure you follow each and every step, carefully and completely. Hope the above helps.

(BTW, there's a slightly related issue: you may also think you can skip over intermediate CHFs, like from having none to going to CHF 2, or going from CHF 1 to CHF4, etc. I addressed that separate problem in a past entry, "CFMyths: "If/when I apply Cumulative Hotfixes, I need apply only the latest CHF, right?"">.)

What you can do, if it's broken

So the steps above are what to be aware of as you're going through the hotfix update process. But what if you did it and it's busted, and you found this note after the fact?

Well, I hope you can use the info above to simply double-check what was done. For instance, check if the directories have mistakenly got things in the wrong place (like if you see a web-inf\web-inf).

Look also at the dates of the files in the zips, and make sure that the dates you show (where files SHOULD BE) are in fact the same dates.

As for the CFIDE issues, besides the above, you may also benefit from just doing a search of your hard drive to find any and all CFIDE directories. You may find many. Again you can check for which are being used by your web server and make sure they are correct for whatever version of CF you mean to be running (for that URL on that web server).

Hope that helps. Or did I leave anything out? Any questions? Comments? Let me know, either way. Like I said, I'd been holding off publishing this because I knew there was a lot that deserved to be covered and it would take time to write. I felt pressed to get it out today, and am trying to remember now all that I've had in mind over the past couple of years on this topic. :-)

Let me know how I did.

In this second entry, I'll address the separate but related problem, particularly if you're running CF as a Windows service, that you may find you get timeout errors from the Windows Services panel itself. I'll share some tips to help with that, which I share often with clients of my independent consulting as a CF troubleshooter.

The first thing to understand is that there is indeed a timeout (configurable) for how long the Windows Services control panel is willing to wait. Beyond that, though, there are some 3 more tricks you can use to avoid that timeout.

Update: I should add that a commenter suggested that another solution was just to kill the task. Um, yeah. I knew that, of course. :-) But the point of this entry, like the last one, is when you DON'T just want to kill it. In particular, I made the point in the last entry that if you want to find out *why* CF is taking so long to shutdown, then you need to let it run to completion to see if it may log some diagnostics. See the last entry for more on that.

But yes, as Russ Michaels noted, sure, you can also just kill the task. I will say I try to avoid doing that whenever possible, to let CF end gracefully, unless I'm forced to kill it for urgency sake.

Note that these tips can be helpful for everyone who runs CF as a Windows service, and indeed for anyone running any application as a Windows service.

Tip 1: There is a timeout set for how long the Windows Services panel will wait

So the first thing to note is that, yes, the Windows Services control panel has a fixed duration for how long it's willing to wait for an action (start, stop, or restart) to take, which is configurable in the registry. If the service control action you request does not finish in time, you'll get an error like "The service did not respond to the start or control request in a timely fashion", with associated event log errors like 1053, 7000, 7009, 7011, and so on.

And technically, you should be able to control that timeout via a registry key, called ServicesPipeTimeout, which is discussed in this Microsoft technote and defined in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control.

Sadly, though I've tried it on multiple machines, I'm not finding it to work.

The technote shows clearly how to either update or add it (if it doesn't exist), including noting that you need to choose the "decimal" option to see the value, which is in milliseconds. The technote does note that you must restart Windows for that change to take effect (and I have done that, and double-checked the value, keyname, and location.)

If anyone has more thoughts on this, why it may not be working for me, feel free to share. Still, you will find many blog entries and discussions proposing this, for CF and other servers, so maybe it will work for you.

The technote doesn't clarify what the default is if the key is not there at all, though I've found some mention that it's 30 seconds. I suppose it could vary by version of Windows (anyone know for sure?).

(Note that there is another key you may see (or hear about) set in the same location: WaitToKillServiceTimeout. That is NOT related to this discussion. That key, instead, controls how long Windows should wait for any/all services to stop when you shutdown Windows itself, which is interesting to consider for itself, but not related to this particular blog entry about Services control panel timeouts.)

Of course, all the usual warnings apply about messing with the registry. But it's the solution, if you need it.

So again, this ServicesPipeTimeout registry key would seem to be the one that controls how long the Services panel is willing to wait for a requested action to finish.

Do beware that it's system-wide setting, controlling all services. What may be good for you (CF) may not be good for all services, so be careful. Second, again, note that the server will require a restart for that to take effect.

Whether it works for you or not, the remaining tips should be helpful.

For instance, if you can't change that registry settings, or don't want to, or you find some day the Services panel is still taking too long to stop a service and you worry it may timeout (the control panel), then there are 3 more tips I often share with my customers (and now you, dear readers).

Tip 2: Use stop/start, instead of restart

Again, if you're being plagued by a service start or stop taking a long time, here's something you may not have considered.

Most often when people want to restart CF (or some other service) they will use the "restart" action in the Services panel. That's logical, of course.

But consider that when you have a problem with the action taking too long (stop and/or start, since a restart does both), both have to finish in that configured timeout time (above).

You can help matters by doing not a restart but a stop and start separately. That way, each action can take whatever the max time is that's configured (per above) to do just the one action.

Sure, it's a little painful. You do have to wait for (and notice) the stop before then doing the start. There's also the risk that even the stop may take too long. I'll offer two more tips related to that.

Tip 3: Close the progress bar before its "times out"

This one may not be as obvious, but it does really help. When you have a start/stop/restart action (for the Windows Services control panel) taking a long time, you risk hitting that timeout above.

But notice that Services panel shows a progress bar indicating the duration of the action you've requested. Here's the tip: if/when it's about to reach the end of its indicated time, note that you can hit the "close" button.

That will prevent it complaining about not being able to stop the service. (And BTW, I've seen situations where hitting that timeout limit not only gives an error but even causes the start/stop/restart buttons to be disabled, requiring a restart of the box!)

Once you close the progress bar, you can use the refresh button in the Services panel (or f5) to watch for when the service goes from "stopping" to blank, meaning it's down. Same for when you "close" it while starting a service: it will go from "starting" to "started".

Tip 4: Consider not using the Services Panel at all

Still another tip (which I use regularly) is that you don't actually HAVE to use the Windows services panel to stop/start Windows services. You can do it from the command line (or a shortcut or batch file).

To be clear, I'm not talking about starting the program itself from the command line (CF, as I've been discussing in these last 2 entries), but the Windows service that starts the program. It's a subtle difference.

As an alternative to starting the Windows Service (for CF) using the Service control panel (Control Panel>Administrative Tools>Services, to be clear), you can use a command line command like this, which I use to stop CF:

net stop "ColdFusion 9 Application Server"

The service name is whatever is shown in the properties for the service you want to stop. (And of course you would use a "start" command instead to start the service. There is no "restart" command, buy you could create a batch file to do both.)

You can run this from the command line (Start>Run>cmd) or as a batch file, but I prefer instead to just setup a Windows shortcut, which you can do by right-clicking the desktop and choosing new>shortcut.

That will prompt you for the command (it just asks you to "type the location of the item", but just enter that command above). It will then ask for a name for the shortcut. I call mine simply "stop cf9".

And while you can then execute it by going to the desktop and double-clicking it, a niftier tip is that with more modern Windows versions (2008, 7, Vista), when you hit the the Window Start menu, it now offers a search feature, and you should be able to type "stop cf9" (or just type "stop " and leave it to pop any shortcuts you've created this way to stop various services.)

So why do I like this approach, of stop/starting the service from the command line instead? Because what happens is that a window pops opens (the traditional black background for DOS windows, so easy to observe) and it shows the stop (or start) taking place, however long it takes (which may be very fast). The key benefit is that the window will close on its own when the action is done (however long it takes). I just watch for the stop to be done, and then I do the start.

There is a possibility, of course, that there will be an error in the shortcut or batch file (or perhaps as a response to the correct command), in which case the window will close leaving no chance to see the error. In that case, I just go to the command line (Start>Run>cmd) and execute the same net stop or start command to see what the error is.

To be clear, using this command-line doesn't stop you or others from using the Services panel.

Conclusion

All that said, though, again, if the reason you need to worry about all this is that your CF Service is taking a long time to stop, and you want to find out why, then I would point you again to the last entry I did, In my last entry, CF911: Is your ColdFusion service taking too long to shut down? Find out why.

Hope all that was helpful, whether you use CF or not. Please do let me know in the comments below.

First, this one will help you perhaps find why it's so slow. You may just have been looking in the wrong place for that diagnostic information. Second, the next entry will offer tips to handle on better handling the situation (that the Windows service is slow to stop, and timeouts in the Windows Services panel itself) which you may need to consider until you do solve the root cause problem (or in case it happens again for other reasons).

(Note that most of this info will apply as well if your problem is that CF's taking a long time to start, also.)

As some of you know, I do CF server troubleshooting as an independent consultant. In helping several people a week, this is a fairly common complaint. This also came up on a mailing list today, so I decided to offer these thoughts here.

Check the logs--but not the "CF" logs

Generally, the explanation for why CF is taking so long to stop (and perhaps also, to start) will be logged (if you are patient enough to wait for it to really go down. More on that in a moment.)

Of course, if you run CF from the command line, then the error would be shown in the command line console. But nearly everyone running CF on Windows will instead be running it as a service. In that case, things get more challenging.

The challenge is that the information about startup/showdown of CF is NOT detailed in the "CF" logs (those shown in the CF Admin, or found in the [cf]\logs directory or buried deep within an instance in Multiserver mode). Those logs (like application.log and exception.log) are often not helpful for system-level problems.

Instead, you need to look in the equivalent of the "console" logs, which in CF 9 or before are found in [cf]\runtime\logs\*out*.log or [jrun]\logs\*out*.log. (In Zeus (the next version, not yet released, which has been publicly shown as running on Tomcat), the will be in the "logs" directory, but as a new file: [zeus]\logs\start.log.)

I refer to these as CF's "console logs" (though as you can see that's not not the formal name) because again this is where CF writes messages that would have been written to the console if you'd started CF from the command line.

(Some will note that there is also info written to the Windows Event logs, but nearly always it just says to see the CF logs. Sadly, it doesn't clarify which logs, or this need to let it end, which is why I'm writing this entry.)

Others will note that if you did start and stop CF (not the service, but CF itself) from the command line, rather than a a service, then you would see any such error messages in the command prompt window. That's true, but it doesn't help you if you already have CF running as a service when this happens. It also would not be an effective way for most to start/stop CF on a continuous basis. But it may be useful for debugging the problem if it happens consistently. See the "configuring and administering CF" docs for more on running CF from the command line.

The key point in this entry is that you will nearly always find something in the log just before CF finally shuts down.

Note that you DO need to let CF shut down, to get that log message

Given what I just said, you will generally need to be patient and to let CF shut down completely to see the message (written in the log just before it finally shuts down). I know this will dishearten some: in the pressure of the moment they just want CF to go down ASAP and so many will just kill the task to be done with it (though of course, sometimes that doesn't work either).

The problem with killing the task is that you then may not see the needed log message explaining why it was waiting so long.

When my customers are complaining of this issue, I try to persuade them to make the painful sacrifice (at least one time) to just go ahead wait and let CF really stop completely on its own, so that they get that log info.

Yes, I realize it may take a few minutes, or even several in some situations. And there are a couple of problems related to that (who can afford that time? and what about the Windows Services timeout). Let's take them one at a time. Because if you need to solve the problem of CF taking a long time to shut down, you have to at least try to get this diagnostic info.

What if you can't "afford the time" to let it stop completely?

As for "who can afford the time" to wait for it to shutdown, here's a tip: if the problem happens fairly consistently (pretty much whenever you stop CF), then just wait to do it (this experiment, where you'll let it take as long as it needs) later in your evening or on the weekend (assuming that's a slower time for you.)

Of course, if you have a cluster of servers, then taking one instance offline is less a problem.

But what about the Windows services panel timeout?

The bigger problem with waiting for it to completely shut down is that you can't "wait forever" for a Windows service to stop. The Windows control panel has a fixed time that it's willing to wait, and if you exceed that it gives an error message (or worse).

The good news is that there are solutions for that, but that's really a whole different subject, and I'll tackle that as a separate entry next (coming up right away).

So what sort of reasons might you find that CF doesn't shut down quickly?

As for what errors that you may find to explain why CF is taking so long to stop, there are many and that would be good fodder for a follow-up blog post. I'll try to get to that in coming days/weeks.

Still, I suspect that most of you will be able to understand what the messages say on your own, now that perhaps you may finally be able to see them. :-)

But certainly, until I do get another entry together on the possible reasons it's slow to shut down, feel free to ask here in the comments or email me directly (charlie at@carehart.org).

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.