At some point you will have to troubleshoot server problems. Trust me - it will happen. It's no good sticking your head in the sand or your fingers in your ears (or both - tricky, but doable). Your first question will likely be, "Where do I find out information about what is happening on the server." Fortunately there are a great many log files in Coldfusion. Unfortunately they are not easy to find, and they contain different formats of information. There are 3 "groups" of file based logs on a Coldfusion MX installation. These groups are mostly the same for CFMX 7 as they are for CFMX 6 and CFMX 6.1 (a few exceptions). Here's a rundown:
Actually, most CF Folks already know about this location. It contains the following logs:
"Error","jrpp-17","06/15/05","14:14:56","ap_v1","Variable undefined... " "Error","jrpp-17","06/15/05","14:15:48",,"File not found: c:\..." "Error","jrpp-14","06/15/05","14:16:37","ap_v1","Error Executing..." "Error","jrpp-22","06/15/05","14:19:41","ap_v1","Element undefined...The jrpp-N identifier is the processid or thread number. The date and time followed by the name of the application (if germane) and the error message. The file path is also included, which is why you should take pains to protect this file from prying eyes.
"Error","jrpp-2134","06/08/05","10:38:00",,"File not found..." coldfusion.runtime.TemplateNotFoundException: File not found: /members.cfm at coldfusion.filter.PathFilter.invoke(PathFilter.java:83) at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:50) at coldfusion.filter.BrowserDebugFilter.invoke(BrowserDebugFilter.java:52) ....
This only applies if JRUN is your underlying Java Ap server (as in the standard edition or Enterprise w/ JRUN). In this folder you will see at least 3 logs. They are named for the name of the "server" or "servers" located in the /runtime/servers/ folder. The naming convention is "*servername*-err.log (or -out.log or -event.log etc). The server name is actually the name of a folder inside of the "servers" folder that contains configuration files for the server in a SERVER-INF subfolder. This is a byproduct of convoluted Java folder management, and one of the frustrating things about Java (where to find everything). So, for example, if there were 2 servers in the /runtime/servers/ folder called "server1" and "server2" you could expect to see "server1-out.log" and "server2-out.log" in the /runtime/logs folder.
2 hints for those of you running standard version CF. CFMX 6.x uses a server titled "default" so you will see "default-err.log", while CFMX 7 uses a server titled (more appropriately) "coldfusion" so you will see "coldfusion-err.log". The information placed in these logs comes from the JRUN server. It may or may not reflect errors in the coldfusion log, but it is usually lower level information, useful in troubleshooting the JVM and server level performance issues
This one is more obscure and not often looked at. This is logging by the sequelink ODBC server. If you are using the ODBC socket driver or any Access DB's on your CF installation you might find useful information here. On a CFMX 7 (or CFMX 6.1 with ver. 5.4 drivers) the path is /CFusionMX7/db/slserver54/logging. You will see 2 types of files here - log files and "dmp" files (dumps). The log files have errors generated by the sequelink server and the dmp files are created when there is an exception resulting in a crash. I have yet to find the .dmp files useful. Usually there is stack trace and an access violation - not much more.
Obviously, in addition to these there are loggers you can set up and customize on your own. There are also the OS logs (event viewer for example) and the web server logs. After knowing where all the information is located the real issue becomes sifting through it. On that note I'll give this piece of advice. If you are troubleshooting a crash, go to each log and extract the information that ranges from 20 minutes before the crash to the recovery (reboot or whatever). Don't draw any conclusions or concoct any theories until you know everything that was going on at that point in time on the server. Then, create scenarios that you think are possible causes and try to figure out a way to test them or (worst case) trap them the next time they occur.
One of the biggest errors I see in troubleshooting is folks who start with 1 piece of information and as soon as they have a guess they go with it. This produces shallow solutions that often do not take all the variables into account. When you are dealing with a crash or performance sometimes having patience is the hardest thing to manage - but it can be your greatest asset.