ColdFusion 8 Upgrade for CentOS and RHEL 5

When we rolled out our big Model-Glue/Coldspring/Transfer upgrade five months ago and ran into performance problems, we did some Craigslist shopping on a Sunday to buy some faster hardware that would hold us over until we could put a real fix in place. We have since acquired a couple of Compaq DL360G4s and I’ve been busy setting them up. Hearing how CF8 is faster than CF7 and confirming the speed boost that JDK 1.6u10 brings to the plate, I knew that we would be upgrading to the latest as part of this hardware update to try and maximize the speed from both hardware and software.

As part of our PCI compliance program, we run our CentOS boxes with SELinux enforcing and this has caused me considerable headaches. Thankfully I’ve documented my steps over the past few years in getting CF and Apache and SELinux to play nicely together so my efforts today were not overly difficult. There are only a couple of modifications needed based on changes between CF7 and CF8.

Configuring CF8 with Apache 2.2 on CentOS 5

1. CentOS 5.2 currently uses Apache 2.2 so I started by installing Apache and the support libraries I would need on the web server side: yum install httpd httpd-devel mod_security mod_ssl
2. Next I extracted and installed CF8 into it’s default location, /opt/jrun4
3. My web server connector was not automatically connected to Apache during the install process but that’s OK. I needed to recompile the connector since mod_jrun is still broken. There were a couple of tweaks here since the connector code is slightly different:
   cd /opt/jrun4/lib
unzip wsconfig.jar
cd connectors/src
// edit mod_jrun22.c per directions in link above
// compile with the following command:
/usr/sbin/apxs -c -Wc,-w -n jrun -S LIBEXECDIR=/opt/jrun4/lib/wsconfig/1/ mod_jrun22.c jrun_maptable_impl.c jrun_property.c jrun_session.c platform.c jrun_utils.c jrun_mutex.c jrun_proxy.c
// continue with directions in link above to strip and check the module
4. Added the necessary configuration to httpd.conf and fired up Apache and ColdFusion successfully.
5. Nearly lastly, I wanted to migrate my settings from the existing server so I used the Packaging and Deployment features to create a CAR file of CF7 settings, SCP’d them to the CF8 box and deployed them. With a couple of tweaks to my firewall rules, I was able to connect to the database from the new web server and bring up my site as though it had been running all along.

Adding Java 1.6 u10 to fix ClassLoader Bug

Not leaving well-enough alone, I also wanted to update the JVM so that I could take advantage of a fix for the ClassLoader bug that slows down CFC-heavy applications. This was a little trickier than I expected due to a broken install of the 1.6 U10 JDK. I started off with the self-extracting file from Sun and exported it to /opt/jdk1.6.0_10 and changed the java.home value in /opt/jrun4/bin/jvm.config to point to /opt/jdk1.6.0_10/. When I tried to start CF I received the following:

# /opt/jrun4/bin/jrun -start cfusion
Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object

I got the same error if I tried the basic “java -version”. Searching around Google basically told me that this means your install is screwed up because it can’t find the most primitive “Object” in Java. Elliott Sprehn asked if I had an jre/lib/rt.jar file and I did not, but I did find jre/lib/rt.pack. It looks like somehow much self-extractor didn’t fully extract. I tried unpacking it myself like so:

/opt/jdk1.6.0_10/jre/bin/unpack200 rt.pack rt.jar

And it did its thing. Afterwards I could both get the Java version and start ColdFusion but I saw some strange errors in the log files that made me question whether or not things were really fixed:

ZoneInfo: /usr/lib/jvm/java/lib/zi/ZoneInfoMappings (No such file or directory)

I decided to try the self-extracting RPM from Sun instead thinking it might do a better job of getting things in the right place. There is a HOWTO on CentOS.org but I didn’t think I really needed to go through all that just so I could point ColdFusion at a different JRE. Turns out the jdk-6u10-rc-bin-b28-linux-i586-21_jul_2008-rpm.bin file from Sun did the trick and created my /usr/java hierarchy:

[root@web4 logs]# ls -al /usr/java/
total 32
drwxr-xr-x 3 root root 4096 Sep 4 09:07 .
drwxr-xr-x 14 root root 4096 Sep 4 09:07 ..
lrwxrwxrwx 1 root root 16 Sep 4 09:07 default -> /usr/java/latest
drwxr-xr-x 9 root root 4096 Sep 4 09:07 jdk1.6.0_10
lrwxrwxrwx 1 root root 21 Sep 4 09:07 latest -> /usr/java/jdk1.6.0_10

I updated the jvm.config to point to /usr/java/jdk1.6.0_10/jre, fired up Jrun and everything ran perfectly with no errors. Not only that, but my application loaded in about 20% of the time it took with the stock JVM. Nice performance bump for first-load!