64-bit ColdFusion - Part III - Configuration

In the last two parts of this series, I covered why you should consider running ColdFusion in 64-bit mode and what steps you would need to take the get the basic installation set up and runinng. In this post, I will cover the steps necessary to configure the system to run in production mode.

Running JBOSS as a service

The first thing you need to do to run in production mode is have JOBSS run as an auto-starting service in Windows. You can use SrvAny to run any executable as a service in Windows. In the case of JBOSS, though, you need to have better integration with the application than SrvAny can provide. I decided to use the Java Service Wrapper, a bit of open source software from Tanuki Software. At the time, there was no native 64-bit Windows compiled binary on the site, but I managed to find someone who had successfully compiled the binary for 64-bit Windows, and he was gracious enough to share it with me.

The wrapper, at its most basic, uses a conf file to configure the Java application service. It provides a lot more power for integration at the application layer if you choose to use it, but for my purposes, basic integration was fine.

The wrapper configuration file contains the configuration information for the Java application, such as heap size and other JVM options, and all the information for the Windows service. You can see my wrapper.conf file to get a sense of how to configure JBOSS using this tool.

The wrapper allows you to configure several important aspects of the environment, including heap size, logging location, application log size and rotation, and the timeout values for application shutdown and JVM exit. Because memory can take time to dump during application shutdown, these last two settings are very important for an application configured with a large heap. In this case, you can see in the file that the heap is set to 12 GB for both min and max, providing plenty of headroom for memory-hungry applications at scale.

Adding the service is as easy as setting up the wrapper confgiruation file and running an executable to install the service with the configured options. If you want to use the Java Service Wrapper, dig into the details on the web site.

Integration with Apache

Unless you want to serve your application directly out of the built-in JBOSS web server, you will probably be integrating with Apache HTTP Server. I first integrated with IIS 6. I found the process extremely difficult (I still don't know exactly what I did that got the solution working), and ultimately it failed to meet my needs. By contrast, I found Apache integration easy and very flexible. My method of Apache integration consisted of setting up mod_rewrite in Apache and adding a rewrite rule to forward all ColdFusion requests to a specific port and path where my application lives.

RewriteEngine On
RewriteCond   %{REQUEST_URI}   ^/(.*)(\.cfm|\.cfc)
RewriteRule   ^/(.*)   http://localhost:8080/myappPath/$1   [P]

 Note in the configuration that you would need to add additional extensions that you might be using beyond cfc and cfm if you wish for them to be forwarded to CF for processing. Port 8080 is where JBOSS is serving my application. myappPath is a Windows symlink to a shared storage device where my application code lives. Windows Vista contains the mklink.exe command that adds symlinks. For earlier versions of Windows, the Windows Resource Kit contained a tool called linkd to create junction points in NTFS volumes. Using this tool, you can create a symlink that points to a directory outside the JBOSS directory and map it to a path inside the cfusion.war folder in JBOSS where ColdFusion lives.

Ultimately, this means that JBOSS is in fact serving the application out of its web server, and Apache is acting as a forwarding proxy to JBOSS. In my case, using Apache as a proxy allowed me to continue to use the shared storage device for the application code respository and still serve the application at the root context to the user, e.g. www.myapp.com/, instead of www.myapp.com/myappPath. That ability might not be a big deal for new installations, but for the migration of existing applications, especially applications with hardcoded links to locations based on the application root, it is essential in order to maintain the integrity of the application.

Those are the basic configuration steps involved in getting the srever ready for production. Beyond these steps, there are steps to take in tuning and slimming JBOSS. I will cover that process in the next installment.