Rob Brooks-Bilson's Blog - Bug

Issue with Ehcache and ColdFusion Query Objects

Mon, 09 Aug 2010 15:50:00 -0400

I submitted a bug for this but the system seems to have swallowed it up without giving me the bug number (probably because I submitted as cf 9.0.1). I've found ~~what I consider to be a serious bug~~ an issue with ColdFusion's ehache implementation and query objects that may bite you if you're not aware of how it works. If I take a query object and stick it in cache, then perform an operation on the original query object such as adding a column or performing certain query of query operations, ColdFusion is treating the query object that's in cache as if it were a copy by reference to the original query object. That is, if I make a change to the original query object, ColdFusion is also applying the change to the version that's in cache. ~~As far as I'm concerned, cache represents a boundary that ColdFusion should not implicitly cross.~~ With most caching systems I've worked with in the past (such as memcached), the cache always acted as a dumb key/value store. Unless I perform an explicit cachePut(), I wouldn't expect that CF would update values in the cache. Here's two code snippets that reproduces the case. The first uses the cfartgallery data source:




select *
from artists

The second example shows how this can be done with a query of a query, based on a different bug Ray found previously (see http://www.coldfusionjedi.com/index.cfm/2009/8/28/Another-example-of-the-QofQ-Bug). In this sample, note that the date gets reformatted by the query of a query and both the original query and the cached version get updated:




  
   
   
   
  








  select mydate, rannum from mydata

The work around for this problem is to use the duplicate() function to make a clone of the query object before doing the cachePut(). Although this works, there are other potential consequences from having two copies of the query around, so be careful. Update: It looks like this is actually expected behavior in Ehcache. Unfortunately, it's not documented in the ColdFusion documentation anywhere, but Ehcache actually has two configurable parameters (as of v. 2.10) called copyOnRead and copyOnWrite that determine whether values returned from the cache are by reference or copies of the original values. By default, items are returned by reference. Unfortunately we can't take advantage of these parameters right now as CF 9.0.1 implements Ehcache 2.0. I can live with this, but it's not what I expected as I've always viewed Ehcache as a "dumb" key-value store and certainly didn't expect this behavior. Even if ColdFusion was running v 2.10 of Ehcache, it's still not something we could easily configure. Since ColdFusion currently doesn't have a cacheNew() function for creating new user-defined cache regions, the only way to turn this functionality off would be to hard-code your cache configuration in your ehcache.xml file for each user-defined region where you want to disable copyOnRead and copyOnWrite.

Fix for Vista's: The User Profile Service service failed the logon. User profile cannot be loaded

Mon, 05 Jan 2009 15:17:00 -0400

Back in November I finally took the plunge and upgraded my home computer to the 64bit version of Windows Vista Ultimate via a clean install. One thing I did immediately after the install was to move the \users directory from c:\users to f:\users. I did this for two reasons. First, the drive Vista was installed on was only 250GB and I could see running out of room pretty quickly given all of the documents, pictures, videos, etc. I had on the system. The second reason for the move is that I wanted to separate my data from the operating system as much as possible to make upgrades and backups easier to manage. Unfortunately, there's no easy way in Vista to relocate the \users directory. If you know what you're doing you can change the location during install by using an unattended install, but this can be very complicated to do and is something that's beyond most casual users. In the end I settled on moving all of c:\users over to f:\users and using symbolic links to point from c:\users to f:\users. That way programs could continue to reference c:\users but the operating system would be smart enough to know and forward all requests to f:\users. Following the directions here I was able to move the directories and files and create the required symbolic links. Everything worked well until I got back from vacation last week and my wife tried to login to her account to pay some bills and was greeted by the following error: "The User Profile Service service failed the logon. User profile cannot be loaded." This seemed odd because she had successfully logged into her account only a few weeks ago. Searching the web for answers turned up this site, which nearly everyone else experiencing the problem linked to. My problem boiled down to this. I could log in to vista using my (Admin) account and create as many new users as I wanted to via the User Management tools in the control panel. In the User Management tool, I could see each and every one of the new accounts. When I booted up the system or choose to Switch Users, all of the newly created accounts showed up on the log in screen. However, any attempt to log in using any of those accounts resulted in the same "The User Profile Service service failed the logon. User profile cannot be loaded" error. The recommended solution involved making changes to a specific registry entry that had become corrupted and contained a backup entry. After looking through the recommended solutions, it was obvious to me that my problem was a little different from the majority of users posting to the site. In my case, there was no corrupt registry entry and no backup key to work with. In fact, there were no registry entries for any user accounts other than my working Admin account. I also didn't have a system restore point that went back far enough before I was convinced that the problem had started. From what I could tell, the problem started after an automated Windows update had been applied. The recommendation made to me and others on the forums with the same problem was to reinstall Vista, something I wasn't keen on doing. At this point, it seemed to me that something must be wrong with the initial creation of a user's profile the first time they log on to Vista. When you create a new user account from the User Manager, Vista doesn't actually create the user's directories until their first log in. When a user logs in for the first time, Vista uses the contents of c:\users\default as a template for the directory/file structure for that user. In the case of the "The User Profile Service service failed the logon. User profile cannot be loaded", I was getting the new user directory (and associated registry entry) was never getting created. A little more digging through the various Windows log files turned up something interesting. In addition to all of the errors stemming from the user not being able to log in successfully was a warning that a particular filename/extension was to long to be copied. Here it turns out that Vista ran into a problem while trying to copy the default profile during the account creation/log in process. Specifically there are two directories preventing the default profile from being created. The first is: c:\users\default\AppData\Local\Application Data As you can see in the following screen shot, the root Application Data folder contains a lot of recursively added \Application Data folders. My best guess is that something went wrong during one of the Windows update processes, resulting in all of the extra recursive \Application Data directories. From the research I've done this doesn't appear to be limited to a single specific Windows update as people have reported the problem as far back as 2007. The second directory you'll need to take a look at is: C:\users\default\Local Settings\Application Data Again, if you look in this directory you should find several more levels of \Application Data appended to the top level \Application Data: In both cases, what you'll need to do is to delete all of the additional occurrences of \Application Data below the root level. Once you've done this any user experiencing the "The User Profile Service service failed the logon. User profile cannot be loaded" error should be able to login.

ColdFusion 8 Causing BSOD on Install For You? I Have a Solution

Tue, 25 Sep 2007 23:03:00 -0400

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.