Note: This blog post is from 2011. Some content, links and indeed comments from others may be outdated--though not necessarily. Corrections are welcome, in the comments. I may revise the content if necessary.Have you ever found (or heard others complain) that sometimes ColdFusion doesn't stop (or it takes a long time to do so)? It can be especially challenging when you're running CF on Windows as a Service, for reasons I'll explain here and in a follow-up entry.
First, this one will help you perhaps find why it's so slow. You may just have been looking in the wrong place for that diagnostic information. Second, the next entry will offer tips to handle on better handling the situation (that the Windows service is slow to stop, and timeouts in the Windows Services panel itself) which you may need to consider until you do solve the root cause problem (or in case it happens again for other reasons).
(Note that most of this info will apply as well if your problem is that CF's taking a long time to start, also.)
As some of you know, I do CF server troubleshooting as an independent consultant. In helping several people a week, this is a fairly common complaint. This also came up on a mailing list today, so I decided to offer these thoughts here.
Check the logs--but not the "CF" logs
Generally, the explanation for why CF is taking so long to stop (and perhaps also, to start) will be logged (if you are patient enough to wait for it to really go down. More on that in a moment.)
Of course, if you run CF from the command line, then the error would be shown in the command line console. But nearly everyone running CF on Windows will instead be running it as a service. In that case, things get more challenging.
The challenge is that the information about startup/showdown of CF is NOT detailed in the "CF" logs (those shown in the CF Admin, or found in the [cf]\logs directory or buried deep within an instance in Multiserver mode). Those logs (like application.log and exception.log) are often not helpful for system-level problems.
Instead, you need to look in the equivalent of the "console" logs, which in CF 9 or before are found in [cf]\runtime\logs\*out*.log or [jrun]\logs\*out*.log. (In Zeus (the next version, not yet released, which has been publicly shown as running on Tomcat), the will be in the "logs" directory, but as a new file: [zeus]\logs\start.log.)
I refer to these as CF's "console logs" (though as you can see that's not not the formal name) because again this is where CF writes messages that would have been written to the console if you'd started CF from the command line.
(Some will note that there is also info written to the Windows Event logs, but nearly always it just says to see the CF logs. Sadly, it doesn't clarify which logs, or this need to let it end, which is why I'm writing this entry.)
Others will note that if you did start and stop CF (not the service, but CF itself) from the command line, rather than a a service, then you would see any such error messages in the command prompt window. That's true, but it doesn't help you if you already have CF running as a service when this happens. It also would not be an effective way for most to start/stop CF on a continuous basis. But it may be useful for debugging the problem if it happens consistently. See the "configuring and administering CF" docs for more on running CF from the command line.
The key point in this entry is that you will nearly always find something in the log just before CF finally shuts down.
Note that you DO need to let CF shut down, to get that log message
Given what I just said, you will generally need to be patient and to let CF shut down completely to see the message (written in the log just before it finally shuts down). I know this will dishearten some: in the pressure of the moment they just want CF to go down ASAP and so many will just kill the task to be done with it (though of course, sometimes that doesn't work either).
The problem with killing the task is that you then may not see the needed log message explaining why it was waiting so long.
When my customers are complaining of this issue, I try to persuade them to make the painful sacrifice (at least one time) to just go ahead wait and let CF really stop completely on its own, so that they get that log info.
Yes, I realize it may take a few minutes, or even several in some situations. And there are a couple of problems related to that (who can afford that time? and what about the Windows Services timeout). Let's take them one at a time. Because if you need to solve the problem of CF taking a long time to shut down, you have to at least try to get this diagnostic info.
What if you can't "afford the time" to let it stop completely?
As for "who can afford the time" to wait for it to shutdown, here's a tip: if the problem happens fairly consistently (pretty much whenever you stop CF), then just wait to do it (this experiment, where you'll let it take as long as it needs) later in your evening or on the weekend (assuming that's a slower time for you.)
Of course, if you have a cluster of servers, then taking one instance offline is less a problem.
But what about the Windows services panel timeout?
The bigger problem with waiting for it to completely shut down is that you can't "wait forever" for a Windows service to stop. The Windows control panel has a fixed time that it's willing to wait, and if you exceed that it gives an error message (or worse).
The good news is that there are solutions for that, but that's really a whole different subject, and I'll tackle that as a separate entry next (coming up right away).
So what sort of reasons might you find that CF doesn't shut down quickly?
As for what errors that you may find to explain why CF is taking so long to stop, there are many and that would be good fodder for a follow-up blog post. I'll try to get to that in coming days/weeks.
Still, I suspect that most of you will be able to understand what the messages say on your own, now that perhaps you may finally be able to see them. :-)
But certainly, until I do get another entry together on the possible reasons it's slow to shut down, feel free to ask here in the comments or email me directly (charlie email@example.com).
For more like this: