Dave Carabetta Blog Banner


August 31, 2006

Two Important Bugs in the Adobe ColdFusion MX 7.0.2 Release


It's been a while since my last post, and one major reason for this is because I have been utterly tearing my hair out trying to figure out why a simple migration from a ColdFusion MX 6.1 instance to a ColdFusion MX 7.0.2 instance simply wasn't working correctly. Hours and hours of time have been spent trying to figure out why client variables weren't be stored correctly when updating their values. During the debugging process, I came across two pretty important bugs in the 7.0.2 release. One probably isn't so bad because it seems to only happen with the internal JRun web server (which nobody should use in production anyway), and ColdFusion is at least consistent with how it handles it. However, the second bug is an important one to consider.

Double JSESSIONID Values Being Set

If you're using the Enterprise version of ColdFusion MX, you have the option of using the J2EE session variable mechanism rather than the built-in ColdFusion session variable mechanism. If you're not familiar with the difference, read this page in the LiveDocs to understand each option. I'll still be here when you get back -- don't worry.

Now that we're all back, the JSESSIONID is critical to ColdFusion being able to "look up" your stored session structure on each page request. And since I need to be able to replicate sessions in a cluster, which only J2EE session variables support, this is a must-use feature for me. However, when using the internal JRun web server (which you should only use for development), when you request your site's root (i.e., http://www.mysite.com/, ColdFusion wrongly sets two JSESSIONID values, which can cause it to "lose" your session scope on subsequent requests. Here is an example HTTP header that is set on an initial page request to a site root:

http://beast:8200/

GET / HTTP/1.1
Host: beast:8200
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 30
Connection: keep-alive

HTTP/1.x 200 OK
Set-Cookie: CFID=102;expires=Thu, 14-Aug-2036 13:20:27 GMT;path=/
Set-Cookie: CFTOKEN=66021081eab5f673-3609FCE3-CF52-FC2B-25E974A728406FC5;expires=Thu, 14-Aug-2036 13:20:27 GMT;path=/
Set-Cookie: JSESSIONID=583033e973025152237c;path=/
Set-Cookie: JSESSIONID=58306b4060d425456d5c;path=/
Date: Tue, 22 Aug 2006 13:20:27 GMT
Content-Language: en-US
Content-Type: text/html; charset=UTF-8
Connection: close
Server: JRun Web Server

See the bug? There is a double Set-Cookie directive that sets not one, but two JSESSIONID values, effectively creating two sessions on your server for every one. This has a nasty side-effect in that more server resources are taken up per user because they technically have two sessions for every one, even though only one is actually used after the initial request. Interestingly, if I were to manually add the index.cfm page to the URL request, i.e., http://www.mysite.com/index.cfm, only one JSESSIONID value is set. So the bug occurs when requesting your site's root document without explicitly typing the desired CFM template. (And yes, if you note the Date value, you'll see just how long I've been trying to figure these bugs out!) Lastly, I should note that when I did a test in my MX 6.1 instance, the same bug exists there. So this isn't exclusive to CFMX 7.

Old DataDirect Drivers Ship with MX 7.0.2, Breaking Client Variable Updates

In my opinion, this bug (and yes, it's a bug) is the much bigger one of the two because this is one that will find its way out to a production environment if you're not aware of it, and has nothing to do with the web server being used. A long story short, Adobe ships the DataDirect 3.3 driver set in the 7.0.2 bits (released on 6/28 of this year), even though the 3.5 driver set was released as a TechNote last October. So much for the point releases being cumulative updates!

You might be wondering why this is such a big deal to me. Well, there are two reasons. First, we use Oracle 10g Release 2, which only the DataDirect 3.5 driver set supports. Second, it turns out that client variable records (in the CDATA and CGLOBAL tables) were not being updated, which meant that once you logged in to our web site (where a few client variables are set) and then clicked to a subsequent page, it would appear as if you had never logged in. The initial insert of the record was working fine (which you can see in the HTTP header sample I pasted above -- it's the CFID/CFTOKEN value), but any updates to the record would silently fail (I say "silently" because ColdFusion handles this for you under the hood, and it doesn't log anything when problems occur). I was going absolutely nuts trying to figure out why it wouldn't update, and the Spy feature of the JDBC drivers (described at the bottom of the aforementioned TechNote) simply wasn't working. After thinking and thinking and thinking, it belatedly occurred to me that the Spy features were only baked in to the 3.5 driver set. So, on a hunch, I ran the CF script below between my MX 6.1 instance (which was working perfectly fine) and the MX 7.0.2 instance to check the driver versions. (Note: The output is written to your log file, so your screen will be blank.)

<cfset drivernames = "macromedia.jdbc.oracle.OracleDriver, macromedia.jdbc.db2.DB2Driver, macromedia.jdbc.informix.InformixDriver, macromedia.jdbc.sequelink.SequeLinkDriver, macromedia.jdbc.sqlserver.SQLServerDriver, macromedia.jdbc.sybase.SybaseDriver" />
<!--- replace all spaces --->
<cfset drivernames = replace(drivernames," ","","all") />
<cfloop index="drivername" list="#drivernames#">
   <cfobject action="create" class="#drivername#" name="driver" type="java" />
   <cfset args = arrayNew(1) />
   <cfset driver.main(args) />
</cfloop>

The MX 6.1 results:

[Macromedia][Oracle JDBC Driver]Driver Version: 3.50.13 (016217.009407.012821)
[Macromedia][DB2 JDBC Driver]Driver Version: 3.50.12 (016217.009407.017715)
[Macromedia][Informix JDBC Driver]Driver Version: 3.50.12 (016217.009407.003505)
[DataDirect][SequeLink JDBC Driver]Driver Version: 5.4.0038
[Macromedia][SQLServer JDBC Driver]Driver Version: 3.50.13 (016217.009407.011311)
[Macromedia][Sybase JDBC Driver]Driver Version: 3.50.12 (016217.009407.007110)

and the MX 7.0.2 results:

[Macromedia][Oracle JDBC Driver]Driver Version: 3.3.48 (008852.005015.004259)
[Macromedia][DB2 JDBC Driver]Driver Version: 3.3.48 (008852.005015.007851)
[Macromedia][Informix JDBC Driver]Driver Version: 3.3.48 (008852.005015.002208)
[DataDirect][SequeLink JDBC Driver]Driver Version: 5.4.0038
[Macromedia][SQLServer JDBC Driver]Driver Version: 3.3.48 (008852.005015.006337)
[Macromedia][Sybase JDBC Driver]Driver Version: 3.3.48 (008852.005015.003526)

After seeing this, I swapped out the old 3.3.48 driver set with the 3.5.13 driver set and everything has been working without issue since.

If anybody on the Adobe ColdFusion team happens to read this, the installer bits need to be updated with the 3.5 driver set. If it passed your regression tests such that it was officially released as a TechNote, then all subsequent "cumulative" updaters and downloadable installers should contain the updated drivers. Further, the fact that the 3.3 drivers ship with MX 7.0.2 means that your System Requirements page is wrong because the 3.3 drivers do not work with Oracle 10g Release 2. Also, please don't call something "cumulative" if it is, in fact, not cumulative. Since I was under the impression that the Updaters were cumulative, it obviously wasn't my first thought to check the JDBC driver version for a regression. Now I need to go back and look at the web connector versions and other items to make sure that those were properly baked in to the latest release. Lastly, If you're not going to update the drivers, then you have to clearly state this in the Release Notes, as there was no mention of this whatsoever.

Anyway, I hope my two weeks of pure frustration helps somebody solve any related setup issues they might be having. Incidentally, my set is ColdFusion MX 7.0.2 on Red Hat Enterprise Linux 4.0 (SELinux turned off) using the internal JRun web server. The above bugs appear in my environment and I do not have a means of testing others. If you'd like to try and confirm these issues in other environments, go ahead and comment back here what you find.

Once last shout out to Jochem van Dieten for sticking with me on my forum thread on this subject. It was very much appreciated.



Comments
Mike G's Gravatar Did you knotice if this happens when you do cflocation or not? We found, when migrating from CF5 to CFMX, if you did something like this

cflocation url="somewhere.cfm?#mysessiontoken#"

(leaving off the addtoken param) that CF would assume addtoken=yes and double up the session tokens.

The fix was to either remove the #mySessiontoken# var from the url param or add adtoken="no"

Could this be what you are seeing?
# Posted By Mike G on 8/31/06 at 6:08 PM
Dave Carabetta's Gravatar Hey Mike. Nah, we never append the CFID/CFTOKEN value to the URL manually, nor do we ever have addToken="true" (or not specified, which implicitly makes it true). This is definitely a bug in the underlying machinery. As I said in the post, once I changed out the JDBC drivers, everything worked perfectly fine without one single code change.
# Posted By Dave Carabetta on 8/31/06 at 6:13 PM
Alex Hubner's Gravatar Funny thing is that Macromedia.com (afaik) use the internal Jrun webserver for production. In fact, I know many people who use it because of the Jrun connector problems (both for IIS and Apache). Currently I have a costumer using a sollution based on Apache mod_proxy and Jrun built-in webservers, bypassing the connector (that does not work well for clustered instances - see http://devnulled.com/content/2006/07/have-you-had-...).

Any workaround will be very appreciated. I was burning my head trying to understand why my sessions are lost so frequently under this cluster.

Thanks!
# Posted By Alex Hubner on 9/1/06 at 2:54 PM
Julian Halliwell's Gravatar Damon Cooper explains why Adobe deliberately didn't include the 3.5 drivers with 7.02 here: http://www.adobe.com/cfusion/webforums/forum/messa...
# Posted By Julian Halliwell on 9/3/06 at 4:54 AM
Damon Cooper's Gravatar Hey Dave, we have shipped the DD 3.3 drivers on purpose, no mistake. We got burned with CFMX 6.1 by just updating the DD drivers to the latest version, running our regressions and believeing DD had done due diligence on the driver set wrt stability, memory leaks, hangs, etc. Turns out thta wasn't the case. We (I) learned the hard way that any "generally recommended update" from us of ColdFusion that is going to update the DD drivers HAS to go through a major CF version closedown to ensure they get enough "airtime" with Beta customers to ensure a) issues are found and b) we have enough time to report to DD, get fixes and get those re-verified.

Sorry for the confusion.

The Sys requirements page does indeed show Oracle 9 R2 supported, but only with "Oracle 9 functionality", which means we ran the 3.3 driver regressions against that version of Oracle and all regressions passed.

Now, we also have made available the TechNote that has the latest 3.4 and 3.5 (I believe) DD driver downloads for CF customers, but there have been problems like hangs and stability issues with some of these driver versions, and regression problems for things like CLOBS and BLOBS for Oracle and issues, so unfortunately it's a matter of picking the right version for your needs at the moment. The 3.3 driver version we shipped in 7.0.2 was the safeest version for customers in general, and that's why it's in there.

The 3.4 and 3.5 versions have been getting better as customers report issues and we work with DD to correct, and they give us new drops, and we post them with their known issues, but I refuse to make the same mistake I did in CFMX 6.1, where I trusted that the newest driver set was stable on a 3rd party's word. We're moving towards "trust but verify", with a full closedown cycle.

For the next major release, we have a fiull closedown cycle available to find the hairy issues, so we're likely going to go to the very latest, and make use of all the latest API's, etc, since we have time to find any issues.

Hope that clarifies the deal on DD drivers in CF.

WRT the dup-jsession issue, let me look into the status of this one....

HTH

Damon
# Posted By Damon Cooper on 9/3/06 at 2:32 PM
Dave Carabetta's Gravatar Hey Damon. Thanks for the very thorough explanation. Your "cautious" approach is both understood and appreciated, but there is still an issue where client variable updates do not execute when using the 3.3 driver set. Now, if you were to set up a test case where you set some variables, click away, and come back, it works. But my site's code did not work until I swapped out the 3.3 drivers with the 3.5 drivers (and it's not something I can post publicly).

Anyway, that being said, there should be a note in the Release Notes that the 3.3 drivers are what ships with 7.0.2, and provide a link for the 3.5 driver set TechNote for those who are using Oracle 10g R2 (which is an increasing number since it's been out for over a year now) or are experiencing other database-related drivers. Ironically, you note that you ship the 3.3 drivers due to customer issues, but I need the 3.5 drivers in order to use ColdFusion.

Thanks again for your time.
# Posted By Dave Carabetta on 9/4/06 at 3:06 PM
Damon Cooper's Gravatar Hey Dave, you definitely shouldn't need the 3.5 drivers in order to use ColdFusion.

I'm not sure what was happening in your case, but all regressions definitely pass with the 3.3 drivers. These are the same drivers we shipped with CF MX 7.0 and if your statement were true, thousands of developers/customers would have complained of broken functionality, but that's clearly not the case.

I'll ask Engineering Escalation to take a look into your issues further and see if we can figure out what the deal is.

Sorry for the frustration, and yeah, we should have release-noted the fact we shipped the 3.3 driver set with 7.0.2, for sure. Sorry about that.

Damon
# Posted By Damon Cooper on 9/5/06 at 5:08 PM
L Strand's Gravatar Outstanding post. It's very well presented. We're close to moving from Oracle 8i to 10g with Cold Fusion MX. This could have been a gotcha and the worst type of problem -- intermittent. We'll pay close attention to driver versions during testing. Kudos.
# Posted By L Strand on 11/16/06 at 3:30 PM
Dave Carabetta's Gravatar L Strand, glad this will help you out. I can't tell you how frustrated I was trying to debug this!
# Posted By Dave Carabetta on 11/18/06 at 5:24 PM
Mike Collins's Gravatar As far as the double session id, I found that by adding the below to application.cfm it allows the cflocation to set the initial cookie before you begin using the session. I will be entering an issue on this as well.

<cfif not isdefined("cookie.jsessionid")>
   <cflocation url="#cgi.SCRIPT_NAME##cgi.QUERY_STRING#">
</cfif>
For testing
<cfdump var="#cookie#">
# Posted By Mike Collins on 3/2/07 at 4:47 PM
Rama's Gravatar Hi All,

i have one application with coldfusion version 6, now i have to migrate entire code to 7 what are the changes i need to make, and i am changing the server from windows to unix,if any one knows please tell me.
# Posted By Rama on 1/28/08 at 4:57 AM
mgwalks's Gravatar is there a way to tell if the updater is updating?
# Posted By mgwalks on 3/12/08 at 4:06 PM

© Dave Carabetta, 2005-2010. This blog licensed under the Creative Commons License. Some rights reserved. This is a personal weblog. The opinions expressed here represent my own and not those of my employer. Blog software provided by Raymond Camden.