An Architect's View

Surfin' Safari

Check out Dave Hyatt's great weblog about Apple's new web browser!

More Macromedia Mac OS X

A one-stop shop page for information can be found at Macromedia - Server Products for Mac Users.

On Safari

Apple's new web browser is very nice although it's quite buggy. I love the look'n'feel and it's very fast. I like the minimalist mode with all the toolbars turned off. I like the integration with the Address Book (which proved how little I'd been using URLs in my contacts over the years - more on that in another blog entry!). All sounds good so far. But, like the curate's egg, it's only "good in parts".

As several people have noticed, JavaScript is poor - you can't login to HoTMaiL for example (well, you might say that's no bad thing!) - and Flash Remoting does not work (which is probably also a JavaScript issue since I believe Flash relies on the browser's JavaScript API in order to make HTTP requests). I've reported both of these through the built-in bug reporting tool (a nice touch). All the same, I'll keep using it, and l look forward to the 1.0 release!

Drool!

Back in June, I switched from Windows to Mac and got a nice shiny G4 PowerBook. At the time it was the "middle" model. Fast forward a few months and things have changed a lot. The brand new Apple - PowerBook G4 17" is an awesome machine. Aside from the stunningly obvious big screen, it has some great innovations: light sensing keyboard backlight, FireWire 800, AirPort Extreme (54Mbps!), Bluetooth... all built-in. Definitely a high "drool" factor. And a brilliant advert showcasing the new PowerBooks!

CFMX for J2EE on Mac OS X

I downloaded the Mac edition and discovered it is a .jar file. I was hoping it might be. The installation offers you a .ear file deployment or a .war file deployment - I chose WAR file and was rewarded with cfusion.war and rds.war. Out of curiosity, I went to my Tomcat installation and created a new cfmac directory under /home/tomcat/webapps. Then I unpacked the cfusion.war file (jar xvf ~/CFMXJ2ee/cfusion.war) and restarted Tomcat. http://localhost:8080/cfmac/CFIDE/administrator brought up the ColdFusion MX Administrator.

Of course, Tomcat doesn't give you all the features of JRun, but it's interesting to see it running on top of Tomcat, alongside my installation of BlueDragon!

---

1.8.2003 - Guess I should RTFM since that provides full instructions for installation on Tomcat!

More Mac OS X Goodness

Christian Cantrell has plenty to say about this in his article, Macromedia - Designer & Developer : Logged In: Macromedia Expands JRun and ColdFusion MX for J2EE to the Macintosh OS X Platform.

JRun & CFMX for OS X

It's sort of 'old' news, even though the announcement has not been made officially. Macworld has this snippet from the Expo - ColdFusion gets X support. The downloads are accessible on macromedia.com: JRun 4 Developer Version, ColdFusion MX for J2EE (JRun Mac OS X Developer Edition). JRun for Mac OS X can also be purchased in the Online Store. No doubt there will be a lot more information published about this later today.

cflock (again)

It's been a while since I posted about good practice locking but an issue keeps coming up which needs to be written down: I see a lot of code like this:

<cfif not isDefined("application.somevar")>

    <cflock type="exclusive" ...>

        <cfset application.somevar = somevalue>

    </cflock>

</cfif>

This isn't safe! Consider what happens if two requests hit this at the same time - they can both find application.somevar is not defined and then they'll both initialize it. The cflock only ensures that the updates will be done one at a time. In order to be safe, the entire condition needs to be locked to ensure only one request will actually initialize things:

<cflock type="exclusive" ...>

    <cfif not isDefined("application.somevar")>

        <cfset application.somevar = somevalue>

    </cfif>

</cflock>

Now the cflock ensures the variable will really only be initialized once.

---

1.8.2003 - Thanx to Marcello Frutig for spotting an error in my original post (a missing not) and also for a performance tweak: as written, the code above will effectively single-thread every request which is potentially a big deal. Since we're only trying to avoid race conditions, Marcello suggested the following idiom which is much better:

<cfif not isDefined("application.somevar")>

    <cflock type="exclusive" ...>

        <cfif not isDefined("application.somevar")>

            <cfset application.somevar = somevalue>

        </cfif>

    </cflock>

</cfif>

This ensures that no requests will single thread once the application has been fully initialized but still avoids race conditions during initialization. Neat! Thanx Marcello!

MacWorld

I wish I could be at MacWorld... Macromedia has a large booth there this year but I haven't heard many details about our presence, other than it's bigger than usual. As always, it'll be interesting to hear what companies are announcing this year - there seems to be some real gems every year. I heard that one company is offering an interesting prize in their competition: an H2 (Hummer). Just the thing for driving around town!

But I can't spare the time... My team's project is at a very exciting stage now as we iron out the final kinks in the system and do performance tuning and load testing. I'll be publishing more 'tidbits' here in due course and preparing articles for the Macromedia Designer & Developer Center.

A New Macromedia Blog

The recently appointed Server Community Manager has just launched his web log - Christian Cantrell's Perspective - and it's all written in ColdFusion MX! This should be a blog worth reading regularly.

CFMX for J2EE: Shared Document Root

Previously, I talked about how to set up multiple CFMX for J2EE instances on your J2EE server and noted that each instance had it's own document root. Now I'm going to tell you how to have these instances share a common document root - so you only have to have one copy of your CF source files. Unfortunately, it's not entirely straightforward and I'm much beholden to Brandon Purcell for his help in ironing out the specifics of how to do this with JRun.
First of all, you can't simply have the entire document root shared. CFMX has a WEB-INF directory which contains server instance specific data and therefore that cannot be shared. This means you have to be a little creative!
Second, some CFMX code expects the WEB-INF directory to be underneath the document root. Fortunately, this 'fixed' section can shared.
Once again, we have to edit XML files to make all this happen. For each server instance, edit the jrun-web.xml file in {jrun.home}/servers/<instance>/cfusion/WEB-INF/ (assuming your context root is /cfusion). The end of the file looks like this - remove the section in red (if present) and add the section in blue:

  <virtual-mapping>
    <resource-path>/</resource-path>
    <system-path/>
  </virtual-mapping>
  <context-root>/cfusion</context-root>
  <compile>false</compile>
  <reload>false</reload>
  <uri-character-encoding>UTF-8</uri-character-encoding>
  <virtual-mapping>
    <resource-path>/*</resource-path>
    <system-path>{cfmx}/wwwroot</system-path>
  </virtual-mapping>
  <virtual-mapping>
    <resource-path>/WEB-INF/*</resource-path>
    <system-path>{jrun.home}/servers/<instance>/cfusion/WEB-INF</system-path>
  </virtual-mapping>
</jrun-web-app>

{cfmx} should be replaced by the common document root you've chosen for CFMX, {jrun.home} should be replaced by the JRun install directory and <instance> should be replaced by the name of the server instance whose XML file you are editing.
If the section in black isn't present, you can add it although it represents the defaults.
This removes the default document root mapping (in red) and adds two new mappings (in blue):

• a document root mapping to the shared document root
• a WEB-INF mapping to ensure each server instance can find its own private library files

I typically add a third mapping (of /CFIDE/*) to the instance's CFIDE directory - to save having to copy the CF Administrator code from the CFMX for J2EE install out to the common document root. It's up to you - I find it convenient because of the automated builds I do on my systems.
If you put your own libraries in the shared document root's WEB-INF area, under classes or lib, then you need to add those directories to the java.class.path in jvm.config.
Finally, you need to copy the WEB-INF/cfusion/lib/jrun.properties file out of one of the server instances to the corresponding location under the shared document root. This is the piece that has to reside under the actual document root rather than the installed WEB-INF.

JRun Clustering & Session Replication - How does it do that?

Both clustering and replication work over the network and do a lot of things automatically for you. If you have two physical servers on the same network subnet and create clusters on both of them using the same cluster name, then the clusters will automagically find each other when you start them up. That means the server instances on each of those physical servers needs to be unique across both servers - server instance names must be unique within a cluster and a cluster can span physical servers. Similarly, session replication can be set up to have an application on one server instance buddy up with a set of other server instances running that application, anywhere else in the extended cluster. Once the server instances are up and running, buddies will automagically find each other.

Let's look at a slightly more complex setup and see what this allows us to do. Consider the following server setup:

• Server 1, instances cfmx11, cfmx12, cluster cfmxprod


• Server 2, instances cfmx21, cfmx22, cluster cfmxprod


• Server 3, instances cfmx31, cfmx32, cluster cfmxprod

Three physical servers, each with two instances of CFMX, using the same cluster name on all three servers. If you connect your web server to this cluster, wsconfig will set things up so your web server will 'boot' off one of the instances but will then treat all six instances as 'proxy servers' (in the jrunserver.store file). Any request (to a /cfusion context root if you followed some of my naming conventions) will be routed to one of the six instances (and that session will then stay on that server).

If you take down one of your servers, any active sessions will be lost unless you've set up session replication. So let's assume we've set up session replication as follows:

• cfmx11 buddies with cfmx21 and cfmx31


• cfmx12 buddies with cfmx22 and cfmx32


• cfmx21 buddies with cfmx11 and cfmx31


• cfmx22 buddies with cfmx12 and cfmx32


• cfmx31 buddies with cfmx11 and cfmx21


• cfmx32 buddies with cfmx12 and cfmx22

With this setup, each server instance has buddies on other physical servers. That means that if we take down one physical server, all active sessions on that server will migrate to their buddies. Let's reboot Server 1. Active sessions on cfmx11 will migrate to either cfmx21 or cfmx31 and active sessions on cfmx12 will migrate to either cfmx22 or cfmx32. No downtime for your users!

So, how does it do that? It uses JINI. JINI let's each server broadcast its services so that other servers (on the same subnet) can automatically discover them. JRun's clustering mechanism uses JINI to discover other servers on the same subnet that host clusters with the same name - and merges them all into one big cluster. Similarly, replication uses JINI to discover on which servers the named buddies exist so that session data can be shared over the network. This is a good example of how powerful JINI can be - you don't need to configure other hostnames or IP addresses into your system: JRun just takes care of it for you. But you do need to be slightly careful - JRun searches the subnet for matching cluster names so if you have a cluster called cfmx on your machine and your colleague also has a cluster called cfmx on his machine, you could suddenly find both machines sharing the load! Choosing your cluster name is therefore quite important!

CFMX for J2EE: Session Replication with JRun

If you've created your cluster (see below), you may decide to make your system more robust by enabling session replication. There are some important caveats however:

• You cannot enable session replication if you store any CFC instances in session scope. CFC instances do not serialize / deserialize fully (because they are full-blown Java objects and session replication is not designed to replicate complex Java objects, only simple data types).
• Session replication works over the network and, for CFMX, cannot use the file-system persistence feature mechanism in JRun.

Having decided to enable session replication, here's how you go about it in JRun. This assumes you have already created a cluster according to my earlier blog entry with server instances called cfmx1, cfmx2 etc. As before, load the JMC in your browser and do the following:

• On the Home page, in the main frame under Application Servers, click cfmx1 to see the J2EE Components on that server.
• Under Web Applications (main frame), click CFMX Application to see the overview of that application.
• Check Enable Session Replication (this auto-enables File-based Session Persistence which we will disable manually later).
• For New Replication Buddy, enter cfmx2 and click Add
• cfmx2 should now be displayed in the Session Replication Buddy List
• Click Apply
• Go back to the Home page - click the Home link in the top left corner.
• In the main frame under Application Servers, click cfmx2 this time to see the J2EE Components on that server.
• Under Web Applications (main frame), click CFMX Application to see the overview of that application.
• Check Enable Session Replication (again, this auto-enables File-based Session Persistence which we will later disable).
• For New Replication Buddy, enter cfmx1 this time and click Add
• cfmx1 should now be displayed in the Session Replication Buddy List
• Click Apply

Now you need to disable File-based Session Persistence because it conflicts with the CFMX custom class loader. You can't do this inside the JMC so you have to edit the jrun-web.xml file for each server instance using your favorite text editor:

• {jrun.home}/servers/cfmx1/cfusion/WEB-INF/jrun-web.xml
• {jrun.home}/servers/cfmx2/cfusion/WEB-INF/jrun-web.xml

The session config section needs to looks like this:

    <session-config>
       <persistence-config>
          <active>false</active>
       </persistence-config>
       ...

By default, the <active> flag is true, it should be changed to false as shown above.
Now restart your server instances and your session data will magically be replicated between server instances!

CFMX for J2EE: Creating a JRun cluster

In order to cluster CFMX instances, you need to have multiple server instances, each containing a CFMX installation. For example, I create server instances called cfmx1, cfmx2 etc and then a common context root of cfusion under each of these. Then I create a cluster in JRun and add in the server instances. Note that JRun clusters contain server instances - a server instance can contain several different applications, each with their own context root. A request to the cluster for a particular context root will be served by any one of the server instances that have that context root. More on this later.
For JRun, open the JMC (JRun Management Console) in a browser and do the following:

• Click Create New Server (top nav, main frame) to get the add server pop-up
• Enter cfmx1 as the JRun Server Name
• Click Create Server
• On the next page, you can change the port number if you wish to use your own scheme rather than whatever JRun allocates for you - I use 8300, 8400 etc for the Web Server Port Number and 51030, 51040 etc for the Web Connector Proxy Port Number - then click Update Port Numbers
• Click Finish and the pop-up will be dismissed
• Click Refresh Now if necessary on the main panel to show the updated port numbers on server cfmx1
• Click Create New Server again and repeat the process for server name cfmx2 (and change the port numbers if desired)
• Click Refresh Now if necessary on the main panel to show the updated port numbers on server cfmx2
• Click Create New Cluster (top nav, main frame) to get the add cluster pop-up
• Enter cfmxXXX as the Cluster Name where XXX identifies the system, e.g., cfmxdev.
• Click Next
• Select both cfmx1 and cfmx2 from the list and click Next
• It should confirm the servers were successfully added - click Done

Now you can start both CFMX server instances and then run wsconfig to configure your web server connector to talk to the cluster you just created.

CFMX for J2EE: Manual Installation

When you download your copy of CFMX for J2EE, you have a couple of options for installation. My preference is to have the installer produce the EAR file cfusion.ear and then do a manual installation of this. The installer asks for your CF Admin password and the context root - if you do a manual installation, the context root you entered in the installer is irrelevant because you can control the context root later. Once you have cfusion.ear, unpack it manually:

jar xvf cfusion.ear

This creates cfusion.war, rds.war and a META-INF directory.
Now go to your J2EE server instance where you want to run CFMX. Create a directory, named for the actual context root you want, e.g., cfmx. Go into that directory and unpack the WAR file from above (jar xvf /path/to/cfusion.war). If you want to enable RDS to this server, you need to create a CFIDE context root directory (alongside the directory you just created above) and unpack the small RDS WAR file there (jar xvf /path/to/rds.war). Start your server instance and then, in your browser, open http://<server>:<port>/<contextroot>/CFIDE/administrator/index.cfm. Go through the first time dialog and you're done!
I've been installing servers this way on JRun (and other J2EE servers) and, whilst it may seem like extra work, it's actually more flexible - you don't need to re-run the entire installer every time, just create a directory and unpack the WAR file. Depending on the functionality of your J2EE server, you may now create a cluster of these instances - I'll show how to do that in another post shortly. Note that each context root has its own ColdFusion document root - the directory you created under your server instance. In another post, soon, I will show how to have server instances share a common document root.