Lately at Emergent Path we have been building applications using ColdFusion on the server side and Flex on the front end to create very compelling Rich Internet Apps. I have settled on a standard set of technologies and frameworks that provide a standard way of building web apps, and I wanted to share my thoughts.  I am hardly alone in the direction I am moving. Anecdotally, several people I know have been building applications in a simliar way, and blogs and mailing lists are starting to fill with technical questions around various parts of the solution.

On the client, we use Flex with the Cairngorm framework to build well-organized, maintainable code. Cairngorm has a reputation as being a little heavy, and we have experimented with variaous cusotmizations and simplications of the framework. There are other Flex frameworks out there, but Cairngorm at the moment is the most widely used, so that is our current standard. Flex handles the View and Controller aspects of the application.

On the server, we use ColdFusion 8 (and that's important, upgrade your server!) with Coldspring to handle the Model. Coldspring is robust and scalable and is rapidly becoming my favorite ColdFusion framework. It only handles the model, and it is a complimentary technology to Fusebox, Mach-II, Model-Glue, Coldbox, and in this case, Flex. 

Coldspring supports the Transfer and Reactor ORM frameworks, but to date we have not used them in any development projects. We tend to customize the model code, and ORM for us has no clear advantage over other code generators. We have been using the Illudium Pu-36 Code Generator for our base model generation. It is a fairly limited tool, supporting only 1:1 table-entity mapping, but it is very easy to use and allows for customization of the code templates to suit your own architectural style.

Under this paradigm, our ColdFusion apps end up with an Application.cfc and index.cfm in the root, the coldspring folder, a model folder, a services folder (for remote service proxies), and that's it. The Coldspring.xml config file, and any other folders (such as upload/download directories, db scripts) can be held outside the webroot and accessed through the local file system. Images and CSS elements are held in the Flex source folder and deployed at compile-time to the proper location.

This paradigm offers simplicity, rapid development, scalability, and good code organization for long-term maintainability. I've been thinking about making an acronym for it, but I haven't come up with anything yet. 

As I noted earlier, I dropped my attempts to use a SoHo NAS product in favor of building a NAS from spare parts and a couple of extra items (an SFF case, SATA card and extra drives). The total cost of the DIY NAS was about $700, and it did involve some time for configuration. Cost-wise, if you are billing your time, it probably comes out to a wash to go DIY or buy the Netgear ReadyNAS NV. The ReadyNAS NV is a step above the products I tested in cost, features, and functionality.

However, I have found other uses for the new NAS that make the configuration effort worthwhile, at least for me. We have been running an installation of SugarCRM, but a little while ago we had to re-purpose the machine it was running on, and we had not taken the time to re-install SugarCRM anywhere else. Enter the DIY NAS, a full-featured Ubuntu 7.1 server. In a couple of hours, we were able to install and configure a base deployment of SugarCRM Community Edition. (If you have worked with a CRM system, you know that installation and configuration is just the beginning of the effort for building and maintaining an effective  system). I expect theSugarCRM system to be low traffic in the short term, so pulling double-duty as a file server and CRM application should be fine. Long term, we will need to port the CRM system to more powerful hardware, but for now we have added significant capability to our business at minimal cost. We may also set up the NAS as our local LDAP server in the office, though as a small business we are not yet at the point where domain services are a real necessity. 

For small business, the combination of ever-faster computer hardware and open source software provides a low-cost avenue to business automation that was once the province of huge corporations. Today, any mom-and-pop shop with some technical skills or a few thousand dollars for consulting services can deploy enterprise-class business automation solutions. In one sense, it signals a loss of competitive advantage for big enterprise, and it knocks down an argument for scale in business, which is the cost and complexity of such solutions. There are still lots of other reasons why scale matters, but it is interesting to see how IT evolution has become an equalizer for small businesses.

Recently, I bought a NETGEAR SC101T as a pure, inexpensive solution for my growing storage needs. Only after the initial install did I read the fine print and find out that the box only supports Windows clients. I need Linux support, and I want Mac support, too (*nix support), so Windows-only is a dealbreaker for me.

The SC101T also has this crazy proprietary software you had to install to make it work. I returned it right after I figured all this out.  I replaced with the a new one- the Thermaltake X-Duo RAID system. That thing barely even functioned. It managed to install the drives once in a linear array, but there was no option to convert to RAID 1 (the reason I bought the thing), and subsequent attempts to reboot and re-install failed because the machine could no longer pick up an ip address from my dhcp server. As far as my network was concerned, it was dead. I returned that one over the weekend.

I finally gave in and built a file server using spare parts and the drives from the SC101T plus another drive for RAID 5 on the storage partition.  I spent maybe an extra $50 over the cost of the X-Duo RAID, including case, power supply, and extra drive., and the system too me less time to get working properly than the X-Duo RAID, which never did what I wanted it to.

Please someone tell me when this category of products matures enough to be useful.

My first week using Ubuntu on the desktop has, overall, been a very good experience. Over the last ten years, I have tried several times to switch from Windows to Linux using a variety of distros and strategies. In the past, there have always been deal-breakers - critical applications that would not work on Linux, or that were sufficiently hard enough to deal with that I felt the tradeoff was just not worth the trouble.

This time around, I am happy to report, much has changed. Ubuntu is, in my estimation, now a perfectly acceptable alternative desktop OS for certain situations.  It is not (nor do I expect it to be) a 100% replacement for Windows or Mac OS X. As a friend in the Linux world once said, it is really hard to compete with a company that spends billions of dollars a year on R & D. Still, for all its limitations (and there are limitations), desktop Linux is now a workable everyday solution.

Hardware Support

The major challenge for Linux on x86 hardware is, as it has been for years, providing good hardware support for the vast universe of x86 hardware available in the market. On this front, Linux has made huge gains in the last five years, both from a distro standpoint (see Ubuntu's restricted driver manager) and from a vendor standpoint. Hardware vendors are no longer totally blind to the Linux phenomenon. In fact, I have been able to find usable drivers for all of the hardware I have in current use, including the printing and scanning functions of my Brother MFC-9700. 

Nevertheless, driver support still lags behind Windows. ATI display drivers have become notorious for their spotty Linux compatibility (are you listening, AMD?) . Linux does not support motherboard-base RAID systems (called fake-RAID by the Liunx crowd because the on-board RAID chipsets use motherboard resources for actual operation). 

Even in situations where drivers are available, downloading, installing, and configuring them is not the job of a novice. It took me several hours to properly configure my MFC-9700 so I could both print and scan with it. Let's just say that unless you are comfortable in a Linux command shell, adding this kind of functionality to your system is not in the cards right now.

If you are looking to migrate away from Windows, either individually or as a strategic move for your business, take the time to investigate vendors who supply hardware that is certified (and supported) on Linux. Dell, with its certified Ubuntu offering, is now the big dog  on the block in the desktop Linux market. Dell also sells systems with Red Hat Enterprise Linux, so they have experience in this market, and realistically, Dell is only going to offer products that they are 100% sure they can support. 

If you are more adventerous, you can install Ubuntu on almost anything, and hardware support for add-on cards and peripherals is very good, but be prepared to spend a lot of time browsing the Ubuntu forums, blog sites, and vendor sites, and keep a Terminal window open, because you are going to need it.

Functionality Gap

I have, in the last week, added support for almost everything in my system, although there is a qualification to that statement. I switched from an Intel-based system powered by an Asus P5W DH Deluxe tweaker motherboard and an ATI x1900 PCI-E video card because of reported (and experienced) compatibility issues with Linux. My new hardware profile is an Asus MN2-MX motherboard with an AMD CPU and a Geforce 7200GS series video card.

So what is working now? First, I added support for my Bose Companion 3 USB speaker system. If you haven't heard these Bose sound systems, get to your local electronics store (Frys has them on display) and take a listen. The sound quality beats every other PC-based sound system out there, hands down. The system recognized the presence of USB audio right away, but I couldn't get any sound. After digging through the Ubuntu forums and some other sites, I figured out that I had to disable the on-board sound support from the Ubuntu config files and set the USB audio as the default audio system. Once I did that (and it sounds easier than it was), everything started working immediately.

 I also managed to get my 160GB iPod Classic mounted  (listening to The Clash - London Calling right now), although it was little trickier than I thought from my first look at the blogs. Apple changed the iPod database recently enough that older software meant for older iPods was not working for my Classic. A couple of hours later, I got the necessary software installed, but I still could not see my iPod. A quick check of hardware using the dmesg command revealed that my iPod was attached to the system as /dev/sdc1, but it was not mounted. Mounting a drive is easy, though:

#sudo mount /dev/sdc1 /media/ipod

After mounting the volume, my iPod appeared and Amarok (my music player of choice because it can use MySQL/Postgres to store its database) was able to import the database from my iPod and play all of my music.

I have not re-visited the problem of synching with Windows Mobile. I might just wait a little while and see how Windows Mobile support shapes up in Hardy Heron (Ubuntu 8.04). 

Somewhat unexpectedly, I was able to add full support for my dual monitor setup, including installing and configuring the awesome Compiz Fusion UI for Gnome.  I probably spent an entire day on this solution, though, so consider your time factor before you make the move to install it. Compiz Fusion is an Aero-like UI for Gnome that uses your system's 3D rendering engine to provide cool visual effects. Take a look on YouTube for some cool examples of what you can do with Compiz Fusion. 

Limitations

There are, alas, still applications that are not available for Linux. The most important missing application, purely for compatibilit issues with web sites, is Internet Explorer. My wife's primary business web site is an IE-only affair at the moment, so for her, Linux just isn't a realistic option right now.

Some network services may be complicated by the use of Linux in heterogenious environments. If you are looking at replacing a set of Windows desktops with Linux, do your homework first. Get a couple of machines set up and see how well they play with domain services, network shares, network printers, and the like.  Providing sufficient support for Linux desktops in an enterprise environment is going to be dependent on having certified hardware and software solutions (check out Dell) and a trained IT support staff that can solve issues like getting network printers and shares to work with these new systems. All in all, the support costs are probably still going to outweigh the benefits of throwing off the Windows licensing model for desktops, but that's a judgement that IT execs will need to make for themselves.

We just got a new server delivered, a Supermicro Twin 6015. My plan for this server is to slice it up into virtual servers to better utilize its resources. I have been looking at all sorts of virtualization technology, but I wanted to use something free and open source. Poking around for information, I found a new technology for Linux called KVM. KVM is a Linux kernel module that allows you to run virtual systems on newer Intel and AMD hardware with built-in virtualization support, which my server has. Even better, Ubuntu 7.10 includes KVM support in the distribution, so installation and setup is a snap- or should be. When I got to the part about installing a new VM using the kvm command, I hit a serious snag. The Linux installer started and died with an error like this:

(!) Direct/Util: opening ‘/dev/fb0′ and ‘/dev/fb/0′ failed
–> No such file or directory
(!) DirectFB/FBDev: Error opening framebuffer device!
(!) DirectFB/FBDev: Use ‘fbdev’ option or set FRAMEBUFFER environment variable.
(!) DirectFB/Core: Could not initialize ’system’ core!
–> Initialization error!
Could not initialize SDL - exiting

I spent several hours trolling the Net looking for solutions. What I gathered from my research was that the installer was expecting the presence of a graphics framebuffer  which my system did not have.  In fact, my system didn't have any graphics, it was installed as a headless server.

After a lot of frustration, I finally installed Gnome on the system and logged into Gnome to see if I could set up a framebuffer in /dev/fb0 for the installer to use. Out of curiosity, I started a Terminal window from within Gnome and ran the kvm command to create a new VM. Voila! The installer started and ran OK. 

UPDATE: I discovered a limitation of this technique on Intel processors. The limitation is documented in the KVM Wiki entry on real mode emulation with Intel processers. AMD processors are not affected by this issue. The easiest way to get around the problem is to install the guest OS via more traditional installer systems like anaconda that do not employ a full GUI. 

I think you can also get around the bug by using VNC to run the guest OS installer.  I am going to try that technique and report my findings.

Digging further on my Java heap issue, I decided to try to figure out what was causing these objects to remain in memory during the life of the request. I modified my code so that all the beans were instantiated in the request scope. I still maintained a function in the main cfm template to set properties of the object in the XML document, and this function accepted an object as an argument. I thought this might have some effect on the ability of CF to garbage collect the objects, but I decided to see what would happen anyway. My test showed a clear trend toward a larger heap size when indexing 10,000 documents, although the heap in this test maxed out at 158 MB and seemed to have some ability to clear memory along the way.

Next, I modified the inline function so that it used the object bean in the request scope rather than accepting a bean as an argument. Under this scenario, the beans would all be instantiated in the request scope and used in the request scope, all within a single cfm page. Would that be enough to allow gc to remove the objects from memory? Under this scenario, the heap maxed out at 140 MB, a bit lower than previously, but perhaps not significant.

After that, I modified the XML routines so that the XML documents were also created and used in the request scope and never passed from one place to another. At this point, I was now using component, but not passing any complex datatypes from place to place, instead simply referencing them in the request scope. This time around, the heap peaked at 137 MB. Moving from unscoped to request scoped variables and eliminating passing complex objects between components seems to have had a limited impact on the amount of memory used in the heap during the indexing process.

As an aide, in these later cases, I made it a point to click the Run GC button in the CF Server Monitor right after the request finished executing. In all cases, the heap dropped off to roughly 20 MB. That means that these requests used anywhere from 40 to 180 MB of memory in the heap to process the same data against the same indexing engine.

It would seem that the use of components as beans to hold data creates a serious potential performance problem for CF-based apps in cases where those beans are persisted (e.g. in the application or session scope) or where many beans are instantiated in a single, long-running request. I don't see any problem using beans in other scenarios, e.g. using beans to store a small number of records returned from the database, or using a bean to model a form in an HTML or Flex front end. I would be cautious, though, of using a large number of beans in a request or persisting beans in the session scope where they may not be garbage collected.

Potential Solutions

Adobe needs to figure out a way for garbage collection of components to be handled more efficiently. In my case, the objects sitting in memory have no further value after being used once in a loop, and they should be subject to garbage collection. My suggestion would be to implement NULLs for variables in CF, perhaps using javacast notation to allow developers to specifically mark objects for deletion.

I gave this technique a shot in my last code iteration, assigning the bean variable to javacast("null",""). (The CF docs specifically warn against  doing this, saying that unpredictable results will occur). My test demonstrated that, rather than eliminating the beans from the heap, the use of this function caused the heap to skyrocket to over 140 MB within the first 2,000 documents.

My suggestion is for Adobe to implement NULLs and allow developers to explicitly mark objects for deletion. Anyone else have a suggestion? Let's hear it. This is an issue that needs to be resolved.

Stil trying to sort out my indexing issue in my application, I decided to start adding components back into the mix to see when memory would start to be affected. I had a theory that the beans used to hold each object were not being garbage collected, and I wanted to prove it.

I added in the SolColdFusion component for indexing and commiting documents to the repository and removed my inline code. Indexing is a single method that accepts an XML document and posts it via HTTP POST to the Solr server. Commit accepts no arguments and posts an XML document it generates to tell Solr to commit changes to its index. Using this one component, I found that indexing was just as fast as in the procedural code and the heap size, once again, never went above 60 MB.

For kicks, I created a component called ObjectDAO with a single method, getObject, that called the stored procedure I was using in my inline code to get each object from the database for indexing. Instead of calling the stored procedure inline, I instantiated an instance of the component, and then I called its getObject method for each of the 10,000 objects I was indexing. Once again, I found that the routine processed the data very quickly and the Java heap never went above 60 MB.

Next, I instantiated a copy of my object bean, cmObject, and populated it with some of the base object data for each object as it was pulled from the database, but I did not use the object for any processing. Yet again, processing was quick and the heap never went above 60 MB.

Following the process of adding components one by one, I instantiated my application's normal object DAO, cmObjectDAO, and used the read method to read data from each object in the database to the object component. I didn't do anything with it, just read the data into the object. The processing took longer due to the overhead of twice as many database calls. The heap grew a bit more than in the earlier tests but never exceeded 100 MB and maintained a normal sawtooth pattern as data moved in and out of memory.

In order to make a better comparison between the procedural and OO code, I modified the routine to use the object component instead of using the query data returned from the stored procedure. In this routine, indexing took more than double the time of the procedural routine and the heap size steadily climed from 30 MB to nearly 200 MB, suggesting that object instantiated were not being garbage collected even after they were discarded. In short, it looks like my theory was correct and the beans used to hold the data were persisting in memory until the end of the request, or until the heap maxed out.

Having failed to write a satisfactory parsing and indexing routine in my Model-Glue app for my content system to push documents to Apache Solr, I decided to write a routine that used my CFC layer to retrieve and index the objects, but I removed them from the Model-Glue application and executed them from a standalone template. I got a bit more headroom out of that method, but the heap still grew until it hit the ceiling and the application died.

Not ready to conceed defeat, I decided to write a standalone indexing routine in purely procedural code to see how the routines compared. I had been very surprised to find the issues with heap size in my first attempt, and I wanted to see if writing code in a procedural manner made any difference.

I pulled out the functionality from my application to read objects from the database, create an XML document, add the objects to the XML document, and submit the XML document to the Solr engine for indexing. I used a single standalone template and a custom tag for my indexing engine. In my first attempt at indexing 10,000 documents, I found the engine was able to push more documents at a higher pace than either the Model-Glue app or the component-based standalone app. More surprisingly, I found that the Java heap never went above 60 MB- more or less what I would expect for a system that was properly handling memory.

Does this mean we should all go back to writing procedural code in ColdFusion? I don't think so, but I would love to see the heap issue resolved in a future release.

Building on the previous post, I will walk through the installation process for the software components involved in this solution. I will assume that Windows Server 2003 64-bit is already installed and configured on the server. 

Installing a Java JDK

The first step in the process is to download and install a 64-bit Java JDK. I used JDK 5 for this install. Install the full JDK, not just the Java JVM. ColdFusion requires the full JDK in order to run. Installation should only take a minute or two. I generally leave the install location at whatever the default is for the installer. If you change the default install location, make sure you note that for later.

Installing JBOSS and CF

There are many guides available on the Web for installing JBOSS. Steve Brownlee made a nice set of posts about installing ColdFusion on JBOSS that I found very useful. Steve covers the actual CF install as well, so I will skip the details and leave you to read Steve's very detailed post for CF. 

The key with JBOSS is specifying your JAVA_HOME setting to point to your 64-bit JVM so you can access the larger heap sizes available to 64-bit software. Set JAVA_HOME in bin/run.bat inside the JBOSS root. It can also be set in run.conf, but we will not be using the conf file for this install.

If you have followed Steve's instructions, you should be able to execute bin/run.bat in the JBOSS root and see the ColdFusion server start inside a command prompt. The command window will stay open until the application server is shut down. You can use Ctrl-C inside the command prompt to shut down JBOSS. I recommend stopping the server that way rather than killing the process.

If you saw the command prompt and were able to access a ColdFusion page in the site you configured, you are officially running ColdFusion in 64-bit mode. If only it were that easy. As you probably noticed along the way, there are lots of things wrong with this picture. JBOSS is still just configured in a base state, your ColdFusion app has to be located inside the JBOSS folder, and the application server is running inside a command window. Not exactly optimal. Next time I will cover the configuration changes necessary to take advantage of JBOSS in 64-bit mode.

64-bit Computing Arrives

The era of mass 64-bit computing has arrived. With even low-end servers running multi-core 64-bit processors with 16 GB or more of RAM, 32-bit software has hit the wall and will be phased out in many server applications over the next couple of years, with desktop systems making the transition over a longer period of time.

For Web professionals, the advent of affordable mainstream 64-bit hardware with greater than 2 GB RAM is both a tremendous benefit and, at least in the short term, a significant challenge. The primary benefit is the amazing scalability that can now be achieved using a single server with two or more multi-core procesors and large amounts of system memory. The challenge is that, in order to take advantage of large RAM sizes, applications need to run on a 64-bit OS in native 64-bit mode so they can address all the memory. At this time, ColdFusion 8 (or rather, JRun and several other associated binaries) are natively compiled in 32-bit mode and do not run in 64-bit mode. Adobe has started to port the full ColdFusion platform to 64-bit, beginning with Solaris, but it may take some time before the platform is available in 64-bit deployment on Windows and Linux.

ColdFusion as a Java application

Frotunately, only some elements of CodFusion server are compiled 32-bit binaries. At its heart, ColdFusion is a big Java application that can be deployed on any compliant Java server. Some elements of the platform are not available in a pure Java deployment (Verity search comes to mind), but the core server is fully functional.

There are two or three keys to deploying a Java application in 64-bit mode - a 64-bit OS and a 64-bit JVM to run the Java server, and a 64-bit web server (if you plan to integrate with a web server). I started my deployment project with Windows Server 2003 R2 64-bit, JBOSS Application Server 4.22, and IIS 6.0 64-bit. For reasons that I will detail later, I switched out IIS 6.0 for Apache 2.2 compiled in native 64-bit mode. Here is the software list:

• JBOSS 4.22 - [Downloads] 
• Apache 2.2 - [Sources] - [Unofficial Win x64 binaries]
• Windows Server 2003 x64 (includes IIS 6.0)
• ColdFusion 8 Enterprise - [Downloads]
• Sun JDK 5 - [Downloads] - look for 64-bit binaries

In terms of the licensed software here (Windows and ColdFusion), you can purchase Windows online from many different vendors, just make sure you are buying the 64-bit version. ColdFusion can be purchased online from Adobe, but for Enterprise, I suggest you contact Adobe about the volume licensing program so you can take advantage of volume discounts and upgrade plans. See the volume licensing page at adobe.com for more details.

The unofficial 64-bit binaries were compiled by Jorge Schrauwen, a CS student and software service provider in Belgium. If you plan on using his binaries rather than compiling Apache yourself (which is no fun at all, let me assure you), be a good sport and give Jorge a PayPal donation for his efforts.

I installed JBOSS using the Sun JDK 5 64-bit binaries. You may choose to run the JDK 6; if so, make sure to check adobe.com and the blogosphere for information relating to possible JDK 6 issues.

Next time I will delve into the software install.