A friend of mine was tearing his hair out trying to solve a problem that occurred randomly. For some reason he would get an error about a certain application variable not existing. He showed me the code - and we both agreed that this was simply not possible. The variable was clearly being defined in the application.
The error would normally occur after some amount of down time. If he started the application himself he could never recreate the error. I had him turn down the application timeout to 5 minutes, let the application time out, and we still couldn't recreate the issue.
Turns out the problem was far simpler. He had another application on the site with the same name! The reason the error would occur randomly and after a period of inactivity was that sometimes the other application would load up before the one that was throwing errors.
So this brings up the question - how do you prevent this? On a box that you control this is relatively simple. You could do a global search and replace over all the folders that contain code. Unfortunately, this will only be easily done for cfapplication tags. You would also need to search for this.name but only inside Application.cfc files. It is possible though. (Do I smell a new Friday Puzzler?) On a shared server though this is impossible, and even if you did do a scan, some other client can easily upload code after you scan. (To be clear, this is a problem on a shared server where you share one ColdFusion instance.)
You can help prevent this by using unique application names. Since the only purpose of the application name is to give the code a unique memory space on the server, you don't have to make a 'friendly' name at all. You could use a long name - just be sure the name is less than or equal to 64 characters in length. As an example, consider this code from BlogCFC. It actually uses a "base" name and also adds part of the file path to it. I did this for folks running BlogCFC on shared servers:
<cfset prefix = hash(getCurrentTemplatePath())>
<cfset prefix = reReplace(prefix, "[^a-zA-Z]","","all")>
<cfset prefix = right(prefix, 64 - len("_blog_#blogname#"))>
<cfapplication name="#prefix#_blog_#blogname#" sessionManagement="true" loginStorage="session">
Archived Comments
I've been stung by the duplicate application name issue before. It is a complete pain to diagnose.
Hah! I was burned by this exact issue last week - a co-worker had created a duplicate copy of my application. I began questioning my sanity..
Thanks for the tip.
I've also seen a subtler version of this issue. Incorrectly extended application.cfc's in sub applications.
Basically a developer sets different variables/values in the onApplicationLoad of a parent and child application.cfc, but doesn't give the child it's own applicationname.
That one is also hair-pullingly frustrating to troubleshoot.
I think that Fusebox5 by default uses the application path as the name to ensure that the name is unique. That would be another way to handle it so that you're not likely to run into a conflict.
I used to have this problem myself.
I'm a big fan of your application naming code now.
that's so ingenious and simple.
One way that I try to minimize the amount of hair pulling I need to do in situations like this is by implementing error handling via cferror (or onError if the site uses Application.cfc) and have the error handler cfmail me an HTML-formatted email with a cfdump of cferror and _all_ variable scopes. A quick look at the application scope dump would probably reveal what that problem was in short order.
OT: Yes, I prefer email over logging to a file or database because in practice almost no one bothers to periodically go back and check the logs. An email sitting in your inbox gets noticed immediately. I once had a developer (client of ours) tell me that they didn't like the email method because it sent them too much email! Well... fix your code so it doesn't throw errors then, for goodness sake. Those errors are being seen by your customers!
/OT
I second Scott on the email for error notifications. I have about two dozen sites on shared servers, and use both the cferror emailing in general, and in a wide number of specific areas of pages cftrys with cfmails in them for sending me errors (they actually all go to a special box just for this, so I don't one day wind up with 23,000 MySQL connection problem emails on my "real" email account, but I check the error handling email box as regularly as my "real" email account.
This is not only helpful in the general way of being notified quickly of error problems, but also for turning up that oddball set of conditions that throws an error that somehow never occurred to you in the development phase.
And, as Scott points out, any error being thrown this way should be fixed. And, your customer and/or his site visitor is seeing them, too, so you want to see it, and you want to react right away.