ColdFusion Muse

Checking the Size of the Spool Directory on Windows

If you ever send out a few tens of thousands of messages using CF you know the spool directory can get pretty crowded. If you are like me you sometimes want to keep an eye on it as those messages clear out to make sure there is nothing funky going on. If you use Windows Explorer this can be a maddening experience. Windows doesn't just retrieve a count of files. It retrieves the entire file list and meta data and it redraws the explorer window. When you have 50k messages in the spool folder it can take 10 to 30 seconds just for Windows to refresh the count so you can know how many were added or deleted to the folder.

Instead, I use a little tool called "t4edirsize" from tools 4 Ever. I have a "show spool" batch file on my servers that looks like this:

The output gives me all sorts of information including the number of files in the directory - but it usually only takes 50-200 milliseconds to run. Tools 4 ever command line tools along with Sys-Internals tools (now owned by Microsoft) like "pslist" and "pskill" are essential to your arsenal as a troubleshooter.

Troubleshooting CFHTTP - 3 Tips

Hang around ColdFusion long enough and you will eventually find yourself making use of CFHTTP. The tag allows you to make an HTTP request from your Coldfusion server to an HTTP resource. Why would you want to do this? HTTP is a great low level protocol for data exchange. There's a reason why most web services run over HTTP - it is easy to understand and implement. As for CFHTTP, there are a great many examples, but here are a few.

Read More

Sick Server Troubleshooting Part 3 - In the Soup

Ok... you've made config changes and tested your connections and performance and you know with the certainty of Rush Limbaugh making a right turn that the server is fully tuned and as lean and mean as possible, but you still have a problem. Now what? Well, it's time to look at the code. Start by enabling slow page logging in the CF admin during a high traffic low performance period. Take the list of templates that are running slow and start digging into them to determine why they are dragging their little cyber feet.

Here are a couple of code related items that you might be looking for.

Read More

Sick Server Troubleshooting Part 2 - Things to Try

In step 1 we discussed gathering information. Without getting good information you are shooting in the dark. Make sure you take the time to know the system well enough to make educated guesses about what to try. That's our next step - trying stuff. I started out making a priority list... as in first try A, then B, but it soon became obvious that it wouldn't do to dictate the order in which you would attempt any of these changes.

In fact, some of these changes fall more under the auspices of "best practice" for configuration and you should probably do them regardless of whether they fix your problem or not. Still, if you are tracking a particular issue then you might need to try something, test, and wait for a result. So here are my “things to try” in no particular order. Your experience will have to help you figure out where to go first.

Things To Try

Read More

Sick Server Troubleshooting Part 1 - Gathering Information

I get a lot of calls from folks with dedicated Coldfusion servers who have suddenly developed problems. Usually the server has suddenly stopped responding in a seemingly random fashion. Often the caller indicates that Jrun is "pegged" at 99 percent. If you search through this blog (and many others) you will find a great number of tips and hints on how to attack this problem. The next three posts summarize my own process and give you a quick resource to the posts regarding troubleshooting a sick server.

Keep in mind that there is no substitute for experience. If you are novice at this you will need to get comfortable with the idea that you will spend several hours (sometimes days) working through possibilities. If the server is mission critical and there is money at stake you should consider calling in the cavalry. A troubleshooter is also a unique animal - a "technologist" of sorts. The best troubleshooters have gathered a good deal of knowledge and experience in several areas (app server specifics, database, hardware, networking etc). The best one s are also a special breed that think in a certain way. They make lists, figure out test patterns, know when to make a leap and when to keep digging etc. So with that in mind, let's talk about how to start.

Step 1 is to gather information.

Read More

The "Cannot Create Cookie" Log Entry Explained

If you are like the muse you keep your eye on the log files in the /runtime/logs/ directory. There's some good information in there if you care to poke around. You might notice one item that appears in the *.events.log from time to time - usually in a long list of similar errors. It looks something like:

This annoying error has been popping up for years and I have never had a satisfactory explanation for it... until now! Genuine ColdFusion Guru Jochem van Dieten (Europe's answer to Ben Forta) figured out that this comes from cookie requests sent from client to server that are using reserved words like "expires" and "path" in the cookie name. Who knew? Check out his latest blog entry for a thorough explanation.

The Dreaded Mismatched Column or Data Type Error Revisited

This annoying error that occurs when using JDBC and MS SQL has been around for a while. The JDBC system in Coldfusion caches information about the tables you access. If you change a table (add a column for example) the column ids get out of whack and they no longer match the correct column. For Example, the first time you run a query you might get back the following:

Read More

Scheduled Task Performance

So you have a template that runs fine when you are loading it into a browser but runs like a water buffalo on Percodan when it's run as a Coldfusion scheduled task? Here's a tip I saw on CF-Talk that serves as a good reminder. Take a look at the debug settings. By default, debugging includes the address 127.0.0.1 (often called the "loopback" or "local" address). Coincidentally this is the very IP address that the Coldfusion Scheduler will report as the calling address (cgi.remote_addr) - meaning the template in question will generate all of that lovely debug information. This can result in an otherwise acceptable level of performance turning painfully slow. Muse rule of thumb - disable debugging in production environments. Ok... so sometimes I enable it briefly to get some information when I'm troubleshooting a specific process, but it should always be off during normal operations.

Let me add as an anti-thesis, turn on debugging in a development environment. It's surprising how many developers work without it. Personally, I spend more time looking at the debug info than the actual output. One of the first things you should do when writing a new query for example, is check it out in the debug. How many records returned? How long did it take? Can I make it better? One of Coldfusion's big advantages (in my view) is the copious amount of debug information provided for you with each request. Use it!