22
Replies
Thanks for all the updates, Steve, and for the kind regards. Glad to hear your confidence in CF is restored. 
As for your client variables problem, it is indeed a pernicious one (and that Dave had suggested might be an issue, earlier in the thread).
As for the "why" it's a problem, it's not that there's any direct connection to CFFORM or CFCs. I'll explain things, but it's not a "twitter" answer (which is why few understand it). For those with the stomach to learn the details, here goes.
Rather, it's due to a default configuration that I like to refer to as the parking brake of CF. People often suffer it unwittingly, when people enable Client variables in their app (clientmanagement is enabled for an app), even if they NEVER use them. If you enable that, CF will by default track two "global client variables": hitcount and lastvisit, on every page request (reading them AND updating them).
There's an option which controls this, in each client variable storage setting (on the CF Admin client variables page, selecting each client variable repository) called "disable global variable updates". This option is NOT turned on by default. If it's checked, then CF will NO LONGER read and update those values, EXCEPT on pages that really use client variables.
So what was happening? Likely, you had lots of requests against this server that were causing contention to whatever was your client variable repository (set via ClientStorage alongside ClientManagement, or defaulting to whatever is selected as the default in the CF Admin client variables page). And even if one would say, "no, there was no other traffic at the time", well, there is also a periodic purge of these client variable repositories which happens by default at 67 minute intervals (again, configured on the Client Variables page). If that was running when you tried to execute a page, that page may be blocked because of the deletes happening (from CF) in the repository. Also, even if that wasn't the issue, sometimes there's traffic happening on one's site that is not obvious, which could itself also be causing reads/writes of these client variables.
Unfortunately, the solution isn't always simple. Sure, you can turn off clientmanagement, which worked for you, but I'll share some thoughts for those who may read this later.
You really can only do that if you are not using any client variables anywhere in the app. If you use even one, that page will fail if you disable client variables.
Similarly, you can't just turn off the global variable updates feature, because even if you don't think you use client variables at all, a developer could have slipped in an access to client.lastvisit, for instance, if they somewhere learned it existed.
In both cases, you really need to first search your code to see if there are any references to client.hitcount or client.lastvisit (be aware that technically people can refer to them as client[hitcount], for instance, or even "client.some#var#", but the odds are pretty low, I think.) Then search for any reference to client variables at all. You could search for "client.", but again beware of other ways to refer to them.
Finally, someone may say, "well, I'll just change my default client storage from registry (or database) to 'cookie'". That, too, is not such an obvious fix. If you really are using client variables, then making that switch will effectively cause all client variables currently stored to be "lost" by your users, since nothing will move the currently stored values from the permanent storage to this cookie storage.
Then finally, going back to that purge, that can be quite a drain, too. One common problem is if the client vars are stored in a DB and that DB has no indexes on the keys that CF uses to do the purge. Similarly, one may want to try to do the purge themselves. There used to be an Adobe technote (a Macromedia one, from long ago) that covered that (and showed the SQL used), but there has been a recent purge of old technotes and I can no longer find it. But others have blogged about it, such as this:
http://www.dansshorts.com/post/sql-blocking-and-client-variable-purge
I'll note as well that you can watch the SQL being generated by both every request (using clientmanagement) and the purge process, if you wrap the datasource and watch it with tools like FusionReactor or SeeFusion. I blogged more about such datasource monitoring with FR:
http://www.carehart.org/blog/client/index.cfm/2008/7/22/fusionreactor_datasource_monitoring
As for observing/purging the registry, both take more work. One can watch the registry updates with various tools, such as SysInternals Process Monitor. As for purging the registry, that's really quite a lot harder. For instance, even as I tell you where to find the keys in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Macromedia\ColdFusion\CurrentVersion\Clients, yes, even for Adobe versions of CF), you MUST BE VERY CAUTIOUS. Do not just open regedit and visit this key, to try to do the delete. If it has hundreds of thousands or millions of keys under it (one for each "client" that's tracked), then you’re your expanding that folder this way in Regedit could lock up your machine. Again, that old technote used to refer to a tool that was offered to try to delete them from the command line. Adobe does at least warn people against using the registry (but I doubt many ever see it):
http://kb2.adobe.com/cps/000/ce14cfd1.html
There's no question that this whole issue of client variablesand the global ones in particularare a real sore point for many, and often without them even realizing it. I do wish Adobe would change the default for new installs to not be registry, but I understand that for updates, they can't presume to change that.
I've hinted at a lot of this stuff above in a blog entry I did on the impact of spiders and bots (which can exacerbate this problem, along with session variables), but perhaps I need to post all this additional detail (and more) as a new blog entry. Until then, hope that the info here helps someone, and of course, feedback is always welcome.
/charlie arehart
charlie@carehart.org
Providing CF and CFBuilder troubleshooting services
at http://www.carehart.org/consulting
AdChoices