The built-in web server in #ColdFusion 10: enabling it, configuring it, reconsidering it

That's not really new news, as the same option was offered in CF 6-9. But there are some new things in CF10 to consider about that option, and that's what I'd like to share here.

First, I want to show how if you chose NOT to enable the built-in web server, you CAN enable it after the fact, with just a simple modification to a single xml file (which is a different one in CF10, and I want to show where that is, share some tips on changing it, and point out where to learn more.)

But there are also still more things about the built-in web server that you can control, which you may not readily discern even from the docs, and I provide here additional info with respect to that.

Finally, while in previous releases the built-in web server (which was really the JRun web server) was something generally regarded (even warned in the installer) to be used only for development and testing, the built-in web server in ColdFusion 10 is in fact the Tomcat web server (Coyote), which is a much better web server out of the box, so you may want to consider it even for production.

I realize that last point will be "pushing it" for some. :-) Hey, I'm not saying that you should change anything, just letting you know that some might reconsider things. Hear me out, please. I'm just sharing documented info that might not be so readily found about a relatively new subject for the CF community (so don't shoot the messenger!)

Background

As in previous releases, since CF6, during installation, you're asked if you want to connect CF to an external web server (IIS, Apache, etc.) or to use its internal web server (such as to avoid conflict with another release of CF running on the same machine that may already be connected to the external web server.) It's a helpful option, especially for testing.

It can also be helpful, even after you install, if you may want to see how something works with it (the internal web server) as compared to running a request via your external web server. And again, you may even want to consider using it for production. More on that later.

Enabling/disabling the built-in web server in CF10

So first, if perhaps you didn't enable the built-in web server during installation, and you want to consider it now (for whatever reason), how do you enable it after the fact? (Or how would you disable it, if you had enabled it and now don't want to?)

Again, it's just a matter of editing an XML file, but it's not the jrun.xml file that it was in CF 6-9, since CF10 now runs instead atop Apache Tomcat. And it is, in fact, the Tomcat web server (not to be confused with the Apache web server) that you are enabling with you enable CF's "built-in web server".

You want to edit the cfroot\cfusion\runtime\conf\server.xml file. In there, find the XML entry surrounded by the comment referring to "internal webserver". Here's an example:

(Do be careful to search for "internal webserver" to find this, rather than search for "tomcatthreadpool", as you will find in the XML there is another copy of that line, almost identical, but referring instead to a protocol value of org.apache.coyote.http11.Http11NioProtocol. That's not the one being referred to. More on this alternative protocol later.)

If the connector entry (the one surrounded by the "internal webserver" comment) is commented out, which means the internal web server is currently disabled, and you want to enabled it, just remove the comments.

If it is not commented out, and you want to disable it, then add comments surrounding it.

Do be very careful when working in XML files: you don't want to use a CFML comment (3 dashes) but rather an html/xml comment with only 2 dashes. If you get it wrong, or leave otherwise malformed comments or entries, the file won't be processed, and CF won't start!

After making the desired change, restart CF to cause the new setting to take effect.

The port used for the built-in web server

You can test things by visiting your site at the port indicated by the PORT attribute in that xml configuration line (8500, above). If that port is already taken when CF tries to start, then again CF will not start and you'll need to specify a different port in the file, then save it and restart CF.)

You can in fact find the info above (enabling/disabling the built-in web server, configuring its port) documented in the CF 10 docset, specifically "Installing Adobe ColdFusion 10", and particularly in this section on the built-in web server.

(One minor gotcha in the docs, related to something I already mentioned: in the current CF10 docs, on that page I link to just above, the value shown for the PROTOCOL attribute of the CONNECTOR element is instead a value of org.apache.coyote.http11.Http11NioProtocol. But the value as deployed in CF10 by default is rather the org.apache.coyote.http11.Http11Protocol that I showed. Just pointing this out if one did "search" their server.xml for that whole string above. Also, of course, your PORT could differ. As I said above, just search the file for "internal webserver" which appears in a comment above it.)

Still more options to configure the built-in web server

But there's still more you can do to configure the built-in web server, and that's another main reason I'm writing here.

Did you know you could change the default document root, add virtual directories (mappings, to point to directories outside of the default docroot), controlling directory browsing, and set custom error pages, all with respect to requests made using the internal web server? You can, indeed.

(And FWIW, you could do such things with the JRun web server, too, if you knew how and where to set these things, such as I discussed some in a blog entry from 2002.)

Anyway, for more on these configurable settings for the internal web server, though they are not documented in the CF manuals, they are documented in in an article by Adobe engineer Kavya Maiya, called Working with Tomcat as the built-in application server. After a couple of introductory sections that are not specifically about the built-in web server, she does share these other tips on configuring it starting at this section.

(And for the sake of completeness, I'll note that the info there (which is an article from the Adobe CF Developer center site posted in May after CF 10's release) is also substantially what was offered in this CF team blog entry, Getting Started with Tomcat in ColdFusion 10.)

There's still more you may want to consider tweaking about the built-in web server, but I'll share more on that in just a moment.

Still more on running CF on Tomcat (even without using its built-in web server)

And I'll note that both those resources do discuss some other things about running "CF on Tomcat" (as CF10 does) beyond just using its built-in web server. It's worth considering, because in fact while the Adobe team has tried where feasible to keep CF10 working just like previous releases, there are in fact differences about CF10 with respect to how it runs on Tomcat.

That has nothing to do with the choice of internal or external web server. And some may know that I did an even more extended discussion on this topic in a talk I've given at several recent conferences, "What's New and Different About CF 10 on Tomcat", and you can find the presentation slides and recording here.

Again, the bulk of that talk is NOT about running CF with Tomcat's internal web server, but rather is about just the overall implications (and features and differences) related to the fact that CF runs atop Tomcat now, rather than JRun. There are a lot of interesting and compelling differences. I plan to eventually start blogging about those as well, as some may never otherwise see the info if it's locked up only in the preso. :-)

A couple of final comments about built-in/internal/Tomcat web server

Before ending this entry, I want to make a couple more points that you won't hear too many others discussing for now.

The internal/Tomcat web server: it's not just for testing any more

I hinted at this in the opening, and I want to clarify. Typically, we have long been told to regard CF's internal web server as "just for development and testing, not for production". That made sense with respect to the old (really old) JRun web server that was within CF 6-9. But again, the CF10 internal web server is the Tomcat (Coyote) web server, and while historically it, too, was regarded as "for development or light use only", the Apache/Coyote team have continuously updated it (a big difference from JRun, which stopped development years ago), and many do indeed use that Coyote web server in production.

(Of course, if you DO choose to use an external web server instead, there's nothing wrong with it at all. I'm not asserting folks should stop, or that there are not indeed cases where it DOES make sense to use an external web server. This is just to say that with Tomcat, as compared to JRun, the internal web server is something you could consider for production use.)

And of course, "production" means different things to different people. Some have a site getting thousands of hits per day, others get millions.

Still, there are folks in the Tomcat community who have shared their observations to THAT community suggesting people think twice before presuming you'd always want/need to put an external web server in front of Tomcat. Here are some references to consider.

(Where they refer to "Apache httpd", they mean simply the Apache web server, since Tomcat is formally "Apache Tomcat". And for those who would use IIS, it's reasonable to assume that most of the conclusions in these articles would apply to a comparison with it as well.)

• Myth or truth: One should always use Apache httpd in front of Apache Tomcat to improve performance?
• "Some notes on tomcat connector performance", especially his conclusion, "Apache Tomcat performs on a level comparable to Apache HTTPD. This is at least the case for dynamic requests, but I have seen similar results for static requests."
• Tomcat Expert Series, Performance Tuning (see especially pages 6 and 32)
• to name just a few

Of course, folks should always test things for themselves before making any conclusive decisions.

And I won't deny (as surely some would want to point out) that the reason they prefer an "external web server" is that those web servers often have far greater configurability, or greater security controls, or better support for things like url rewrites, or greater integration with other tools, and so on.

Again, I get all that. I've said it above, and I'll say it again: if you are happy using an external web server, I'm trying to persuade you to change. I'm simply saying that the former conclusion that "we would always want to" just isn't quite as valid as before. If that may help someone, that's the only reason I'm pointing all this out. :-)

For more on the Tomcat/Coyote web server

Finally, for more on the Tomcat/Coyote web server in general, which is known inside the Tomcat docs as the "http connector", including some more "configurable knobs" and choices that you may want to consider, see the Tomcat docs page on it. (By contrast, the "connector" for connecting Tomcat to an external web server is the ajp connector.)

Speaking of alternatives (just within the internal/Tomcat/Coyote web server/connector), I'll note that there is an available choice between "protocols", from the default "bio" to the "nio" protocol, as referred to briefly a couple of times above. CF uses the bio protocol by default. I'm not prepared myself to make any recommendation or indeed further comment on choosing among them.

Same with the many configurable options you'll find listed there. I'm sure some could prove to be very important. I just haven't enough time/experience with them yet to comment upon them.

But I'm sure some intrepid souls will be tempted to explore them, and tweak things, especially if they may be considering using that internal web server for production. Feel free to share what you learn here.

For now, I am satisfied to leave the protocol and all its settings at the default, as I am not yet myself using this internal web server for production.

One last warning about all this: beware that whenever you change settings that CF relies upon, you not only should test them thoroughly but also be sure to always mention the specific non-standard changes you've made when you're seeking help, whether from Adobe or the community. I see this sort of "unstated tweaking" lead to a lot of confusion and challenge when people are trying to help each other on the inter-tubes. Forewarned is forearmed. :-)

I have one more comment to make that is somewhat related to all the above (with respect to the internal "wwwroot" in CF, and how it's now used in CF10 regardless of whether you use the internal web server or not. But since it applies even for those who do not, and they may not be tempted to read this entry, given its title, I'll post that as a separate one soon.