Some people - myself included - have observed runaway memory usage and apparent memory leaks with applications built with certain combinations of CFML frameworks that include Transfer ORM. We spent a lot of time tuning the JVM and looking at code and database usage in our Broadchoice Community Platform (CMS), we worked with Mike Brunt on load testing and tuning (highly recommended - if you have any performance problems, get Mike on your case!) as well as working with Mark Mandel directly on Transfer itself. All that work led to a much more stable system and we decided to just continue investigating as a background task.

[More]

As I Twittered on Monday, the new release of the Broadchoice Community Platform (our hosted content management system) was in QA and had hit zero bugs. QA completed successfully so today we pushed the new release to production. It's mostly a bug fix and minor enhancements release but it contains one new feature I wanted to talk about from a technical point of view.

The Community Platform has a number of "modules" (applications) that you can add to a page and one of those is a list of documents for download (or external links). You add the module to the page and then select documents (from your document library) to add to that module. In previous releases, authors had to add documents in the order that they wanted them to appear on the (generated) web page. We looked at a number of UI options for allowing authors to "rank" the documents within the module but felt most of them were fairly clunky, involving entering ranking numbers to reorder things or up/down arrows requiring authors to move documents one position at a time. Ugh!

Ray pointed me at one of the cool jQuery UI interactions: sortable. It allows you to mark a "container" tag (e.g., a div) as sortable and then users can drag'n'drop the "child" elements into the order they want. You can attach event handlers that fire at various points in the drag'n'drop operation.

Here's how we do it:

That's all you need in the HTML. Then you add the following JavaScript: This causes two things to happen:

1. jQuery marks the sortable div contents as being, well, sortable!
2. jQuery adds an event handler for update - when the drag'n'drop operation completes - that invokes a URL on the server, passing in the serialized data from the children of the sortable div, i.e., the id values as a list in the new order: doctag[]=1,3,4,2. It assumes an underscore as a separator.

The server side code simply updates the module data to put the documents in the specified order.

I ran into an interesting bug in the final stages of preparing the latest release of the Broadchoice Workspace application. I had added a custom getter to an ActionScript object to calculate a complex property, along these lines:

This allows you to say myObj.complexProperty without needing parentheses for a function call (and with a matching custom setter, you can assign to the pseudo-property as well). It's a nice feature of ActionScript that can really make your code much more readable.

The particular getter I added was only valid when certain data in the object was non-null. In all of the mainline use cases inside the application, this was fine. The complexProperty was only ever accessed after testing the condition on the object:

Yes, someCondition was a custom getter as well.

The bug I ran into was that sometimes remote calls involving this object silently failed. I didn't get a fault back. It was almost like the call just didn't happen. Puzzled, I fired up the Flex Debugger (which is absolutely awesome!) and traced through the code. No visible exceptions, no strange paths being executed in the code. More puzzled, I fired up JBoss in the Java Debugger under Eclipse and put a breakpoint inside the server method that was called. Strangely, the code ran without hitting the breakpoint! That showed that the call really was not happening for some reason.

Back in the Flex Debugger, I set a breakpoint just before the remote call and took a very close look at the object in the Variables panel when I hit the breakpoint. It showed the custom getter as a property on the object (as expected) but the value in the debugger showed an exception was thrown retrieving the property. Then it hit me: Flex Remoting tries to serialize the object by calling the getters and it was failing due to the exception - and silently swallowing the exception without telling me, and without executing the remote call!

I updated the getter to return a default value if the condition (myObject.someCondition) was false and, sure enough, the object serialized just fine and the remote call was successfully executed!

Moral of the story: if you add custom getters to ActionScript objects, make sure they cannot throw an exception when the object is in a state where you need to send it to the server using Flex Remoting!

About a month ago, I talked about my experience of setting up clustered ColdFusion instances on EC2. Since then we have migrated the Broadchoice Web Platform completely from a regular data center, where it had lived since launch, to the Amazon cloud and now all of the *.broadchoice.com sites and all of our client sites based on the Web Platform are happily running in the cloud.

We've been very pleased with the performance and stability of EC2 so far and we're comfortable about scaling out as demand increases. We took advantage of Amazon's EBS (Elastic Block Storage) that allows you to mount S3 storage directly as part of the file system on EC2. This essentially replaces the NAS we were using in the data center where all uploaded files were placed. We run two ColdFusion instances on a medium EC2 instance and run MySQL on a separate EC2 instance (actually on the instance that is currently running our AIR application, the Broadchoice Workspace for Salesforce, along with its MySQL database). We replicate the MySQL databases to another server (in a data center) so that we can restore / recover in the event of a problem with EC2. We also run scheduled backups of the EC2 instances to S3.

As I noted in my earlier entry, we're using Apache and the JRun Connector to manage the two instance cluster and failover. I'm still suspicious of the connector due to past experience but so far it has been behaving well and when we restart instances for maintenance, we're generally seeing uninterrupted service, from a user's point of view, as requests silently failover to the other instance.

If you're interested in running ColdFusion in the cloud, you'll need to talk to Adobe about licensing (either Adam Lehman or Kristen Schofield) but they are being very encouraging because they want this to happen. The more of us who do this, the better the argument they can present internally to get the EULA changed to support ColdFusion running in the cloud!

If you want to learn more about how we handled the migration and/or what to watch out for when designing applications that run well on the cloud, feel free to contact me via this blog or directly (c'mon, you know my email address!).

I recently had a bit of a challenge to tackle with our Workspace application and thought I would share some details. As many of you probably know from trying out the application, Workspace is meant to be kept open to fully capitalize on it's collaborative features. The application provides a lot of behavior that is based on real-time communication, such as content being updated or users being added to Spaces. All of this works quite well right now, and we are already working on more features as well as some simplification of the interface to allow new users to get up and running more quickly.

We have, however, noticed a small but annoying glitch that happens as a result of certain real-time notifications that trigger Flex Alerts. Namely, if the application is minimized and an Alert is triggered, when the application is maximized, the Alert does not appear in the proper place. Normally, an Alert will automatically center itself in the window where it appears. But if the application is minimized, this centering does not happen. So when the app is maximized again, the modal Alert is located far in the upper left corner of the screen, with most of it's content off the screen completely. Users had a hard time figuring out what was happening, and since the Alert is modal, the app can't be used until the Alert is closed. This resulted in a lot of confused users!

I set out to solve this issue by triggering a re-centering of any open Alerts when the application is resized, but this turned out to be more difficult than it first appears. At first, this seemed like it should be fairly simple: the Flex SystemManager object contains a property called popUpChildren, which references any PopUp objects that are open. So no problem, right? Just loop over this list and recenter them.

In a frustrating turn of events, Flex Alert objects are not stored in this list. I'm not sure why, but they aren't. This seems like an oversight or bug, but the fact remains that looking at the popUpChildren wouldn't work. This list appears to only contain any PopUp instances created using the PopUpManager, but not any Alert instances. Nor is there a similar list such as alertChildren. It turns out that Alerts are added to the SystemManager's display list but are not actually kept track of anywhere.

The first part of the solution was to add an application resize event handler that loops through all children of the SystemManager's display list and locates any that are instances of the Alert class:

This code actually does work and will recenter the Alert. But in another frustrating turn (and what certainly appears to be another bug), the re-centered Alerts did not display correctly. Any text within the Alert box that was "off the screen" prior to re-centering would not display. I tried triggering an invalidateDisplayList() and invalidateProperties(), but nothing would get the Alert to re-draw the text correctly. I was banging my head against the monitor when my astute colleague Joe Rinehart made a suggestion that turned out to give the desired result:

Essentially, you have to kick Flex in the head by removing the Alert, re-adding it, and then re-centering it for good measure. All of this seems like a lot of hoops to jump through to accomplish something that seems like it should be rather easy to do, but there you have it. Going forward, we'll probably set up some sort of centralized manager class that can be used to create and keep track of both Alerts, PopUps, and any other components that need to display at the very top display list of the application (such as Callouts and Tooltips), and we're also looking at some Growl-like notifications to minimize the use of Alerts. But that's a topic for another day (probably in the very near future though). In any event, hopefully this post will help anyone who ends up in a similar situation!

Oh, sorry, that was the title of the BACFUG presentation by Bill Shelton and Marc Esher (of MXUnit fame)!

Unit testing has defined my working day. I've been working on the licensing subsystem of the next build of the Broadchoice Workspace today and because we practice Test-Driven Development (thanx Brian!), that means writing unit tests "first" or at least alongside the production code.

I started by writing the License bean and an accompanying LicenseTest. The bean has a handful of properties and two methods. The unit test has nine test methods.

Fairly confident that the bean was correct, I moved on to the data layer. Apart from encryption, this mostly follows our well-tested generic Hibernate DAO. That meant only a couple of unit tests.

Once those tests passed, I moved on to the service layer. Six unit tests for four service methods.

At this point I'm ready to write the remote service facade (which implements user-level security) but I'm fairly confident our licensing subsystem will work as expected. 623 lines of code, just over half of which is unit tests (327 lines to 296 production code). I'll probably add some more data layer unit tests since I have a couple of "untested" methods (they're used in the service layer tests).

Unit tests may seem dull and tedious but they really can make your life easier.

Now that the Broadchoice Workspace has been officially released, I thought I'd post a quick entry with some code statistics. I ran the codebase through a line counting tool that gives a breakdown by file, folder, language, etc. We all know that lines of code is not a very good way to judge quality or effort, but it is still interesting in a general way. This is only lines of code, all blank lines and comments were excluded:

• Total Lines of Code: 50,125
• Total Files: 633
• Lines of MXML: 10,784
• Lines of ActionScript: 12,675
• Lines of CFML: 7,730
• Lines of Groovy: 8,878
• Lines of XML: 1,757
• Lines of CSS, HTML, JavaScript, etc.: 7,612
• Lines of SQL: 1,089
• Lines excluded as comments or blank: 15,778

Yesterday I blogged about how I set up Groovy/Spring to send both HTML and plain text emails. Today I want to share a tip about testing those emails. I was using postfix on my Mac as SMTP server. This allowed Spring to connect to, and send the email, but the emails would never leave my machine. My coworker Sean had no problem with mail getting out, so I figured I either had some setting wrong or perhaps it was my cable company blocking the traffic.

I googled around a bit and came across this excellent blog article: fully local testing of email sending web apps (on Mac OS X)

This article describes how to set up postfix to listen to certain domain names and forward those emails to local account. It then goes on to describe how you can setup a pop3 server to get those mails.

The end result is that you can send email to anything at a particular domain and then use a desktop client to check the mail. This is not only cool for Groovy work but would also be useful for ColdFusion as well. I normally use Spoolmail to check CFML generated mail, but that isn't an option for Railo, and it doesn't give a 'perfect' end user view of the mail (especially for combo plain text/html emails like we are testing).

Here at Broadchoice we've been working on our new product for close to three months now. I've gotten a crash course in Groovy, Spring, and Hibernate, all of which are slightly familiar to me from my time with ColdSpring, Transfer, and Java. I'm really digging these new technologies, but of course, I'm a die hard ColdFusion user at heart. A few weeks backs I needed to work on a quick iPhone web application prototype. Joe set up the connection and all I had to do was write CFML (lucky me). Little did I know that along with setting up basic CFML compatibility on the server, Joe also added one of the slickest things I've seen ever in my life as a developer.

The application I'm working on is pretty simple, but I wanted to use Model-Glue 3 for it since - well - you never know when a simple prototype will turn into a large, complex application. The following code snippet comes from a controller used to load bookmarks:

Nothing in the above code should be too odd or even that exciting really. I'm using a service (injected via the beans scope in Model-Glue 3) to retrieve my content. My controller begins with...

Note the beans value specifies which beans configured in ColdSpring should be passed to my controller. I love this new automation in Model-Glue 3. If you open up my ColdSpring.xml file, you will see my beans configured:

Hmmm. Ok, there's my config bean, wheres my contentService bean? Oh yeah - here it is:

You can find the above in our Spring file. Just in case the above didn't quite make get through, let me make it real nice and obvious:

The above line of CFML is using a bean injected from Spring, not ColdSpring, and points to a Groovy file. This is the same Groovy code used to drive the AIR application. No createObject("java") here baby. I'm using the Groovy code just like it had come from a CFC. This is done using a ColdSpring/Spring adapter that Joe wrote. It lets ModelGlue get Java-based beans from Spring. (I'm simplifying it here a bit, but hopefully you get the significance of that!) Once that connection is done, you can easily get beans from the Spring file and inject them into your controller. So for example, when my UserController wanted do handle login, I added: beans="userService,config" and then simply ran a userService.validateAndLoad on the authentication information.

It's always been easy to use Java from CFML, but never has been so sexy! Now to be fair, I did have to use a JavaCast once or twice, but not nearly as much as I would have thought.

If you happen to work with Adobe AIR at some point, and you want to download a file from a server, you may run into this helpful error:

I/O error 2038

Not very helpful. After a lot of digging and trying out solutions, I think I've figured it out. I was doing something like this in a Delegate object:

The problem seems to be the scope of the File object that is used to perform the download. Because it is locally scoped to that method, when the download completes and the completion event is announced, the file object is essentially gone. I'm not sure if AIR is garbage collecting it, or if the variable is just not accessible because it is function-scoped. Either way, I got this error over and over and was pulling my hair out.

The solution is to not var scope the new File object. Unfortunately that seems to open up potential concurrency issues. Because the Delegate object is essentially a Singlton, if I add the file as a public property of the Delegate, and more than one upload goes at the same time on the client, it will get overwritten. That's not good.

I got around it by creating an Object to wrap around my file called SharedFile. This object has a public property which is a File object. In that case, I can do something like this:

So I'm setting the sharedFile.file property to a new File, then using that file object to perform the upload. The I/O error vanishes because the file object is not locally-scoped, and so a reference to it still exists when the completion event fires. Again, I'm not sure of the exact underlying cause of the problem, whether a function-scoped file object is simply not visible when the completion event fires, or whether the AIR runtime is garbage collecting the variable before the completion event fires. Either way, this seems to fix it!