May 14, 2008
A recent post on Brian Kotek's blog about future directions for ColdFusion sparked a lot of debate over whether or not ColdFusion should support AS3 server-side. I want to change the focus here a bit and talk about a feature I've been thinking about that would be potentially useful to a lot of people. I'd like to see ColdFusion 9 support deployment of various services across multiple JVMs - without having to have multiple instances of the full ColdFusion server.
Why would you want to do this? Let me lay out a few scenarios and see if this starts to make more sense. Imagine you have a ColdFusion application deployed on a 32-bit Windows server with 4 GB of memory. The ColdFusion application in question does a lot of XML manipulation and PDF document generation. If you've ever had a similar application in a similar environment, then you know that your ColdFusion application can really only make use of about 1.6 GB of RAM as that's a limit of the JVM on 32 bit platforms. You also know that both XML parsing and PDF document generation are very expensive operations, especially from a memory utilization perspective. Now imagine if you could configure your ColdFusion application such that it was able to off-load the PDF document generation and the XML parsing and transformation to separate JVMs. This would allow your core application to handle the majority of your application functionality while off-loading the processing intensive operations to separate specialized JVMs (as opposed to separate threads on the same JVM). The difference here is that the additional JVMs wouldn't require a full instance of the application server - just the specific processing parts that can be off-loaded. This is exactly how most Enterprise Service Buses deal with distributed processing and I think it would be a killer feature for ColdFusion to have in its bag of tricks.
Of course the benefit isn't limited to just memory limited JVM instances in 32 bit environments. In 64-bit environments, it makes just as much sense as you are still segmenting processing, allowing for better thread utilization, and potentially allowing you to scale out just the type of processing you need to.
What do you think? Does this make sense?
October 9, 2007
In a previous entry I talked about a problem I was having with my laptop blue screening every time I tried to install/run ColdFusion 8 with the default 1.6 jvm. At the time, I believed the issue might be with java 1.6 and some drivers on my machine. It turns out I was only partially right.
I though others in my group had been successful at installing CF8 on their machines, but it turns out that they all had the same BSOD problem I did. After a little more digging, Adam Crump was able to determine that the fault was taking place with a file called fslx.sys. It turns out that this file is used by the Altiris Software Virtualization System that was installed on all of our laptops. We use Altiris for lifecycle management, helpdesk, patch management, and more. The software virtualization wasn't being actively used, but something about it is causing the BSOD. Removing the Altiris virtualization program and reverting back to the 1.6 jvm solved the problem.
We're planning to submit the issue to Symantec (they recently bought Altiris) so they can hopefully issue a fix. Their virtualization software is actually pretty cool, so I'd like to be able to have it reinstalled on my machine again at some point.
September 25, 2007
I've been having problems getting ColdFusion 8 installed on my laptop for months now. No matter how I tried installing it (stand alone, multi-server, j2ee), it caused my computer to Blue Screen during the install process. Everything would go ok right up until I launched the ColdFusion Administrator to complete the install process. After launching the CF Administrator, the computer would continue on for between 1 and 30 seconds before it would blue screen with a BAD_POOL_HEADER error.
I know others are having the problem as well as a Google search turns up several others with the problem but no satisfactory solution.
After a lot of off and on troubleshooting, I finally had a chance to sit down over the past two days and have figured out what the problem is and have come up with a workaround. It turns out that the issue is the JVM. More specifically, Java 6 (and on my machine Java 5 as well) causes the problem. I can cause the BSOD with Java 6 using both ColdFusion 8 and JBoss (without ColdFusion).
Since the ColdFusion 8 installer lays down the 1.6.0_01 jvm, you need a way to install ColdFusion 8 with an earlier jvm. Here's the workaround I've come up with. In my case, I chose to use the 1.4.2_14 version of the jdk:
- Go through the entire CF install (doesn't matter which server method). However, don't launch the CF Administrator to complete the install. If you do this, you'll BSOD.
- Download an older version of the Sun JDK. I happened to test with 1.4.2_14, which seems to be working for me. When I get time, I may test with earlier versions of 1.5, but the latest 1.5 still caused BSOD for me.
- Install the JDK. you may have to reboot.
- Open the jvm.config file (c:\jrun4\bin) and change java.home to point to the JDK you just installed. This will tell cf to use that jvm instead of the 1.6.0_01 version that installs with cf 8.
- Start all CF services. If any are already started, restart them.
- Open the CF Admin to complete the install process. It should complete without error, and without any BSOD.
At this point, you should be good to go.
I should point out that the BSOD problem is most likely a problem with Java 6 and either my video card, or my NIC. I have an IBM T60 with an Intel Nic. Others in my office have the same laptop and nic, but aren't having the BSOD problem. They do, however have a different video card than I do (I have an ATI Mobility Radeon X1400). IBM OEM's the card in my case, so any resolution is going to have to come from them on my end. I have no idea if they will ever resolve the issue, so all I can do is continue to test new JVM versions with my setup as they come out to see if the problem has been resolved.