The Byte Stops Here

As many of you guys know by now, Jason Delmore was among the 600+ laid off by Adobe recently. While I don't know if anyone else in the CF team was affected, I do know that Jason was a tremendous asset to the team.

Reading this in the blogosphere, I was hoping to find some good news. Well, it just so happens that Jason Delmore's resume has an interesting tid bit, a silver lining for all of us CF people.

As you know, Adobe is always hush hush about sales number when it comes to CF. But if you look at the resume, you'll see:

"Product revenue increased 50% Year over Year with 84% Quarter over Quarter at release." That's great news for CF, and a testament to what Jason's helped with.

Just thought to share that with all the bad news going around.

Just saw this, looks interesting. ColdFusion and Lucene 2.4.

Check out Revorg GOAT Search Solution on RiaForge

JVM Tuning has been long a favorite subject of mine. Maybe some day I'll share our JVM Settings in full, but for now you need to do two things.

Update to JDK 1.6 Update 10 - Once CF8 came out, people started complaining that their frameworks loaded slowly, initial page loads were long, that CFC generation took a while, etc. The conventional wisdom was to move back down to 1.5, which didn't have these issues. No more. Update 10, which has long been in beta, is now fully launched, and our CFC generation, slow loading issues are nearly gone. Whereas before it would take minutes, it now takes less than 15 seconds. Besides the other benefits of running the latest 1.6, this one rocks. Download info available @ http://java.sun.com/javase/downloads/index.jsp.

Garbage Collection Settings just for Frameworks - We would occasionally notice hiccups, slight slow downs for GC despite our numerous JVM tweaks. No more since adding two lines. More information is available @ Mike Brunt's blog - http://www.cfwhisperer.com/post.cfm/sun-jvm-1-6-heap-memory-behavior-with-coldfusion-frameworks.

The Two JVM Tweaks:
-Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000

Ok, trying to be as dramatic as I can be in my title about a new undocumented method in CF8 called "getValueWIthoutChange".

You've seen me post before on how hard is to get underlying session information from CF.

When I saw this blog post by Terry Palmer, I almost had to blink twice. If you don't know what I'm talking about, well, his blog entry has all the details.

I'll be looking at the code closer and seeing if we can't do some interesting stuff with it. For now, read on, and enjoy!

I don't know how many of you guys remember Reactor? All the buzz has been around Transfer for the past couple years. We've been using Reactor since 2006 in production with little to no issues.

Now that Doug Hughes posted that he has handing management of the Reactor Framework to Mark Drew, its great news. Read more @ Doug's Blog.

I do have a couple gripes about Reactor though, which I've expressed to numerous people, including Doug since 2006, and I wanted to make them public here.

One is that Reactor doesn't support schema's out of the box for MS SQL 2005. I can't speak for other DBs. If every table in your DB is owned by DBO, i.e. DBO.tableName, then you are fine. But if you are like us, and have multiple Schemas, then you have to hack Reactor. What's worse, the hack is SOOOO simple. Reactor goes through and figures out your DB anyway, and it can figure out the Schema and add it to its call, but it doesn't. Simple right? But we've been running the hacked version for years because Doug thinks "Reactor is stable" so he decided not to change it to add this functionality.

More details @ http://www.reactorframework.com/ticket/42.

The other issue is Reactor creating CF UUIDs when it should be creating MSSQL GUIDs.

My one enhancement for Reactor would be suggesting caching for queries. When Reactor was released, we were still in the CF7 world. But now that queries with cfqueryparam's can be cached, it makes sense to add that.

Excited to see some movement with the framework, and look forward to seeing what's next.