Rob Brooks-Bilson

You'll have to bear with me here because this is a long one. A few months ago we ran into a problem after upgrading some of our servers to ColdFusion 8.0.1 CHF3 from CHF1. We had an application that integrates with a web service running on a remote .Net/IIS server that started throwing a "Connection Failure" message for code that worked fine pre-upgrade. It turns out that in CF 8.0.1, CHF 2/3 there was a "bug" that was fixed for cfhttp:

72744 Fix for CFHTTP making disable deflate as true by default in the header when CF sends an HTTP request, since compression is not handled by CFHTTP client.

Problem for us is that this fix actually broke code we had previously running. Here are the test cases:

Here we have a CF 8.0.1 server running CHF 3:

Execute this code, where we tell CF to pass in two headers:

Wireshark shows CF appending deflate;q=0 to the * which we told CF to pass. This is what was added in CHF 2/3.

IIS 6 gets this and decides to return the data compressed as you can see in the Content-Encoding:

This time, take out the accept-encoding header:

When you run this, notice that ColdFusion appends all sorts of stuff for the Accept-Encoding header:

The result coming back to CF is again compressed by IIS 6:

Let's try this now with CF 8.0.1 with no CHF (works the same with CHF 1):

Run the code passing in both headers:

Wireshark shows ColdFusion passing in only the accept-encoding value we specified. For the TE trailer, we pass in deflate;q=0 which is supposed to tell IIS not to return deflated (compressed data):

What you see next is what we expect to see. IIS is returning the correct data uncompressed:

Now go ahead and take out the accept-encoding like we did last time:

Notice how CF just passes along deflate, gzip, x-gzip, etc?

IIS gets this and returns the content deflated, which CFHTTP can't handle and we get our error:

One last time. Now for CF 9:

Run the code passing in both headers:

What we see in wireshark is the same thing we just saw for CF 8.0.1 up to CHF1:

Data comes back uncompressed as we expect:

Remove the accept-encoding header:

Same values passed as for CF 8.0.1:

And we get compressed data back (and the error again), as expected:

So, what this long exercise shows me is two things:

1. ColdFusion 8.0.1 up to CHF 1 and ColdFusion 9.0 have identical functionality. A hotfix that was applied in CF 8.0.1 CHF2/3 is not present in CF 9.0
2. The change that was made in CF 8.0.1 CHF 2/3 (72744) was not properly implemented. We've fixed this in our CF 8.0.1 CHF3 installs by stripping the class files from the CHF JAR that updated CFHTTP and stuff's working again. I can understand Adobe wanting to tell web servers not to compress by default, but setting deflate:q=0 needs to be done in the TE, not in the accept-encoding header. Putting it there causes the data to be returned compressed.

I filed a bug report on this and verified the problem with Adobe (there's a bug number but for some reason it isn't showing up in the bug base). They've stated they'll be releasing a fix for it in CHF4 for CF 8.0.1. Just a reminder that this issue does not affect ColdFusion 9.

Thanks go to my coworker Adam Crump for helping to troubleshoot and diagnose the issue.

Just a quick note that I'll be speaking at Adobe MAX 2008 in San Francisco. My topic this year is Advanced ColdFusion Caching Strategies. I'll be covering ways to improve application performance and scaling using both ColdFusion's built-in caching mechanisms as well as distributed caching systems such as Memcached JCS, and EHCache.

It's been a while since I've spoken at a ColdFusion conference. The last time was at MAX 2004 in New Orleans where I presented 5 sessions on Coding for Scalability. I'm hoping that this year's presentation on Advanced ColdFusion Caching Strategies will be something people find both interesting and useful as I think it's a topic that's often overlooked but can play a big part in both performance and scalability.

Hot news flash. ColdFusion 8.0.1 has been released with support for 64-bit operating systems. Also included in the release are a slew of bug fixes as well as some tasty new features including:

• Update to core 3rd party libraries (jdk 1.6.0_03, FCK Editor 2.5, YUI 2.3, EXT JS 1.1.1, Spry 1.6, Verity 5.5.0 sp3)
• Nested implicit structure and array creation
• Access to the error stream in cfexecute
• Timeout attribute for cfftp
• Attachment removal after successful send for cfmail and cfmailparam

There is much more to the updater than what I've mentioned here. For the full list of fixes and enhancements, see the release notes.

You can learn more as well as download the update from Adobe's website.

I've been working up a few demos lately that make use of the new layout tags in ColdFusion 8, and while I think they really do make Ajax based layouts much easier than using the Ext js and YUI libraries on their own, there are a couple of issues I've bumped into that have me thinking that their potential may be limited. Let me explain.

Today I was working on a dashboard mock-up to show to some of my colleagues. I wanted to show them how simple it is to do a dashboard in ColdFusion, and I wanted to do it using the new cfwindow, cflayout, and cflayoutarea tags. Things were moving along well until I wanted to add an accordion pane on the left-hand side of the layout. Try as I might, I couldn't find the attribute or value in any of the new tags to make it happen. That's when I realized that accordion panes are only available as part of the Flash based cfform controls. Doh! I don't want to use any Flash in my dashboard demo (I'll leave that to a Flex based demo), just straight HTML/Ajax. There are several options for adding an accordion panel outside of ColdFusion (Spry, Ext js, etc.), but I wasn't expecting that the control wasn't going to be included as part of ColdFusion 8.

This led me to more carefully consider the new UI controls in ColdFusion 8. For many layout tasks, they may be sufficient. However, what really has me concerned is situations like this. I still want an accordion control, and in order to get it, I'll have to mix and match the ColdFusion UI controls with another solution. What I'm strongly considering right now is abandoning the new UI controls all together in favor of a custom tag based approach. It turns out that there are two ColdFusion custom tag libraries that each wrap the Ext js library: cfExt by Dan Vega and ColdExt by Justin Carter. I like the custom tag based approach for a number of reasons:

• Utilizes the latest EXTjs library: 2.x. ColdFusion 8 currently uses EXT 1.x, and it doesn't look like they will be upgrading to 2.x anytime soon.
• Custom tags allow for new feature adds faster than new ColdFusion releases.
• Custom tags allow for community contribution.
• Custom tags give you total freedom to customize should you need features not implemented by the original author.
• Custom tags provide a form of insurance against Adobe stopping future development of the new UI tags. While they have always done a good job of maintaining backward compatibility, there are numerous examples of situations where a particular technology was phased out and new features/functionality halted (cfgraph/cfchart, Flash forms, cfform java applets to name a few)

I hope I don't come off as bashing the new UI tags in ColdFusion 8. I really do like how easy they are to use and will be very beneficial to a lot of developers. If, however, you require more flexibility, you may want to consider implementing UI controls natively in JavaScript, or looking into one of the Custom Tag Libraries mentioned previously.

I'd love to hear what others have to say about this topic.

I realize that this is another "me too" post as the news has already been widely reported. However, it's good news, and it's too good to pass up. Just in case you haven't heard yet, Adobe ColdFusion 8 just won the 2008 Jolt Product Excellence Award for Web Development, presented by Dr. Dobb's Journal.

What makes this particularly nice is that the winners are "selected by a panel of judges consisting of industry insiders, columnists, and technology leaders.", lending much more credibility to the award.

Congratulations to the ColdFusion Engineering team and to Adobe!

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.

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:

1. 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.
2. 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.
3. Install the JDK. you may have to reboot.
4. 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.
5. Start all CF services. If any are already started, restart them.
6. 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.