That might sound weird to everyone looking at the awesome list of new stuff in the ColdFusion 9.0.1 updater that Adobe has released just this week. But let me tell you what it that #1 bug fix is and why it makes the life of my clients so much easier.
As I said, it’s in the Admin API and it’s about the trusted cache. This is a feature that helps to increase the performance of your ColdFusion application, it basically tells the CF server not to check for a changed/updated .cfm or .cfc file when serving a request but to just go with the currently used Java class the CF server knows about. You can “clear” the trusted cache from the ColdFusion administrator manually, restart your CF server or use the Admin API to clear a file or a list of files from the trusted cache (clearTrustedCache() in the runtime.cfc)
The client runs a fairly large CF cluster under reasonably high load and as part of the deployment process of new files, the trusted cache is cleared for those files across all cluster nodes, making use of the Admin API. That worked well so far, but had one flaw (bug #82214): In cases where a file was actually deleted from the file system in a new build/release (or just moved), the Admin API didn’t allow us to remove the file from the trusted cache, but bombed with an error message bubbling up from the Java core that the file couldn’t be found. It rather should check for the existence of the file in the cache instead though.
As a result, even though a.cfm was deleted in the filesystem one could still call and execute it unless we cleared the whole cache for that cluster node or create a literally empty file a.cfm that doesn’t do anything and reset the trusted cache with said empty a.cfm. Clearing the whole cache as a work-around is fair enough but is obviously an unnecessary performance hit. With CF 9.0.1 this issue is fixed, yay. You can now delete a file from the trusted cache even though it doesn’t exist in the filesystem anymore. It’s a tiny fix, but it really make the life of that client much easier.