ColdFusion Muse

Copious File-not-found Errors on Railo/Resin

Periodically I like to peruse log files for common errors (call it a hobby). When I find an error that appears to be reoccurring again and again I go hunting for ways to fix it (if it is truly an issue), or suppress it if it's something irrelevant that is cluttering up the log. Yes I know - it's magic being around with me at times.

Recently we acquired a Railo server with a 25 or 30 of sites on it running a moderate amount of traffic. I had experimented with Railo before but I'm still feeling my way along. This particular Railo server was version 3.2.2 running on Resin. One of the logs I discovered was a JVM default "out" log in the Resin/log directory (jvm-default.log). Taking a peak I noticed long lists of "file not found" exceptions that looked like this:

Page /sitename/index.cfm 
	[C:\data\Applications\resin\webapps\ROOT\sitename\index.cfm] not found

...where of course the "sitename" was an actual site on the server. They appeared to occur in bursts and it did not seem to be related to a particular site (although busier sites were more well represented). In every case the error referenced /webapps/ROOT but a quick look at that disk location made it evident that indeed no web apps were deployed there. Hmmm.... what gives? I turned to the Railo Google group. Luckily Railo Guru Todd Rafferty of web-rat fame hangs out in there and he asked me to send him my resin.conf file. I sent it to him and he returned a solution lickety split. But to explain the solution you might need some background.

Deployment on Resin/Raili

Using CF (or as Railo folks put it "ACF" for "Adobe CF") you set up one or more "instance" of ColdFusion and the connect one or more "site" to the instances using connectors in IIS or Apache. ACF is sort of agnostic of how many sites you have and where those sites might be located. But Railo/Resin work a bit differently. Each site is deployed as it's own application and the deployment is controlled by the settings in the "resin.conf" file (in the conf directory of your Resin install). Now please understand - I'm giving you my explanation and I fully expect folks to chime in and tweak my understanding till I get it right. I'm sure there are other ways to do it and I welcome those explanations. Moving on...

In my resin.conf file (an XML file) I have a section called <cluster>...</cluster> and inside of that there are a series of <host> nodes. There's lots of other nodes in there but we'll just look at the host nodes for now. There is actually 1 host node for every site using Railo on the server. Each of these site specific nodes look like this:

It's pretty easy to see what's going on here. Each site has a starting point and one or more host aliases so that Resin/Railo can "match up" requests it receives with the appropriate code or classes or whatever. In fact TomCat does something similar which makes me wonder if CF 10 is going to change the model - but I digress. Look carefully and you will see another host entry as well that looks a little funny. It has no "ID" string attached to it and the root directory is root (.) - We'll call it the "default" or "catchall" host. It looks like this:



This host entry is important as it sets up the Resin admin and default app params - but it also sets a sort of "default" for serving files.

Todd noticed that this entry came before the rest of the HOST entries. Resin/Railo was deploying this application first followed by the other host entries - each application deployed in order. Between the deployments of this "catchall" application and the "site specific" applications, requests were being passed to Railo. And since Railo did not yet know about the site specific deployments where all the path and alias properties would help it to determine which file to serve (they were still in the queue) it naturally looked in /webapps/ROOT for matching cfm files. Finding none, it threw a "file not found error". So each of my Railo "start" operations was throwing as many errors as there were unhandled requests (with higher traffic sites naturally generating more errors). As soon as the site specific application was loaded the errors stopped for that site.

As Todd pointed out the "fix" was simply to move this host entry to the end of the list of host entries - causing it to deploy last. This get's rid of the file not found errors cluttering up the log on each restart.

Railo Side-note

As I mentioned before, other than experimenting I had not yet paid much attention to Railo. But after hob-knobbing with Mark Drew at a recent conference and assimilating a Railo server into our company I am beginning to work with it on a daily (or at least weekly) basis. Hopefully that will mean an occasional Railo post like this one.