Most Read This Week
ColdFusion Server Recovery
ColdFusion Server Recovery
By: Vlad Friedman
Feb. 28, 2003 12:00 AM
Have you ever built that "killer" ColdFusion app only to have server problems bring your application to a grinding halt? Fortunately, armed with a little knowledge and a few batch files, most issues in ColdFusion 4.0-5.0 are easily resolvable in less than 60 seconds.
Many of these scripts are taken directly from the edgewebhosting.net internal support archives and have been created after many years of troubleshooting ColdFusion servers. The batch files in this article as well as several other scripts and utilities used for recovery can be downloaded at: http://edgewebhosting.net/quickfix.
Even if you don't have a dedicated server, you should still know how to perform basic ColdFusion server recovery procedures. You may need to recover an in-house server, or offer a little friendly advice to the support tech on the line who may not know how to resolve a problem with your shared hosting service.
This article assumes a Windows-based platform utilizing Microsoft IIS as the Web server, one of the most common environments for hosting ColdFusion Web sites.
At this point the dll used by the server to process and send mail, dart.dll, will lock up and go into an infinite loop. This causes the cfserver.exe (ColdFusion Application Server) to lock at 90-100% CPU utilization. Restarting the ColdFusion Application Server service or rebooting the computer seems to have no effect since the affected file remains in the mail spooler's folder.
You can also save and run the following batch file. Make sure to replace the path with the correct path to your CFusion folder on your server.
REM Contents of fixmail.bat
Background: Variable deadlocks occur when several processes or users try to update the same memory in a Server, Application, or Session variable at the same time. On a site that receives a large amount of traffic, variable deadlocks on one site can cripple performance for the entire server. As I am sure you have read in several CFDJ articles, I cannot stress enough the importance of utilizing CFLOCK effectively within your applications. (For example, see "Super Wizards: Using ColdFusion for Data Manipulation and Processing," by Courtney E. Payne; CFDJ, Vol.4, issue 12.)
Solution: If you suspect that you have variable deadlock conditions causing your server to go haywire, log in to your CF Administrator and enable "Full Checking" on the Server, Application, and Session scopes in the Locking section of the configuration. After you have made this change, ColdFusion will throw an error if you try to use a shared access variable without a lock. It's not perfect, but it will catch most missing locks.
Another option is to simply use Studio's multiple file search for the strings "server", "session", and "application" and ensure that you are using CFLOCK with all of your shared variables. This may take a while, but consider it a painful reminder that you must lock your code. A quick browse of your Application.log (\cfusion\log\ application.log) will quickly reveal which CFM files and variables are causing the problem. You can then disable "Full Checking" and fix the code within the application causing the problem.
Background: ColdFusion and MS SQL server are both very resource-intensive applications. In a high-traffic environment, both applications start to contend for the available resources on a server.
Solution: If you can possibly avoid it, do not put ColdFusion and SQL server on the same machine if you intend to run in a mission-critical production environment. You will have a significantly more stable server if SQL is on a separate machine, even if that SQL machine maintains a higher CPU load than your CF Server. If this situation is unavoidable, modify the properties of your SQL server configuration to reduce the amount of available memory resource and CPU worker threads available to SQL Server in the Memory and CPU tabs within the SQL Server Properties in Enterprise Manager. Set the values to a necessary level for your application to avoid overloading your server. Usually 75% of the default values will produce effective results.
Solution: The following steps should resolve the issue:
If you are hosting in a shared environment, call your Web host and ask them to "Unload your site in IIS." They should be familiar with the process.
Several other errors may occur while accessing your MDB file.
Solution: Although this can be caused by several different conditions, most often all that is required is a restart of your ColdFusion Application Server service. If that does not alleviate the problem, most likely your MDB file is corrupt, the database requires a password, or the ColdFusion Server does not have the correct NTFS permissions to access the MDB file. If restarting the service does not resolve your issue, see http://edgewebhosting.net/quickfix/mdb for a set of utilities to repair MDB files or identify the presence of an MDB password.
Please be aware that Macromedia and Microsoft do not recommend using Microsoft Access databases for production environments. We've found that once you start receiving more than 25 concurrent users to your Web application, this problem will reappear much more frequently.
For more information, see Macromedia's notes on the subject: www.macromedia.com/v1/Handlers/index.cfm?ID=1540.
This problem occurs if your server is configured to store client variables in the system registry. By default, the variables are not purged for up to 90 days. On a server that receives moderate to heavy traffic, the registry can become full quite quickly. Once you have reached Windows' maximum allowable registry size, no applications on the server will be able to write additional data into the registry.
Solution: The first step of this solution is to purge the client variables from the registry. This may be accomplished by downloading Macromedia's utility on their support site: www.macromedia.com/v1/handlers/index.cfm?ID=20340.
Unfortunately, the Macromedia-provided utility may run for several hours to clear the entire client variables registry key. We have written an application to perform this process much more quickly:
The second step is a little more difficult. It is highly recommended by Macromedia that you not store client variables in the registry in a production environment. Client variables should always be stored in a database when used in a production environment; preferably a SQL Server database. If this option is not available to you, use the Macromedia TechNote to update your registry to ensure that your variables expire in a timely fashion: www.macromedia.com/v1/Handlers/index.cfm?ID=22419
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads