If you are running Cold Fusion on J2SE 1.4, please read this tech note regarding Sun's End-of-Life announcement. This primarily affects ColdFusion 7 and JRun 4, and should not be an issue at all if you are running ColdFusion 8.
We are about to start testing an update to JRun 4 (Updater 7) which will bring JRun up to date with changes we made to support ColdFusion 8 (including changes to support newer operating systems). If you'd like to take part, sign up here.
It's no secret that my various public sites have been running on various beta, alpha, and even pre-alpha builds of ColdFusion MX 7 for a long time now. I've actually had lots of different builds running at the same time. Well, last night I made some time to do a clean CFMX7 install, and thankfully the process was almost painless.
The first thing I did was back up my CF Admin settings (including data sources and mappings) to a CAR file.
I then uninstalled JRun4 and all CF instances (not entirely necessary, I know, but I had so many bits of different installs laying around that I thought it best to start from scartch). When I was done I checked the Windows Services and found a couple of left over entries (hey, uninstalling alphas and betas is seldom a clean process), so a quick RegEdit was needed to kill those.
Then I run the ColdFusion installer. It threw an error about needing to specify a different install location, and a quick MM Forums search explained that that was caused by a corrupt installer. So I downloaded the installer again, and this time it worked.
I did a new install (not an upgrade), using the JRun + ColdFusion option, as this way I'd have the Instance Manager installed too.
I then restored the CAR file, and recreated a single JVM setting change that I had made previously.
And that was it. Everything seems to be working properly, and I have a clean install to work from. Total time involved, under half an hour.
I love it when stuff works the way it is supposed to!
I first mentioned this half a year ago during my summer CFUG tour, but a few of you have asked about it recently, and so ...
ColdFusion MX Enterprise features support for multiple ColdFusion instances. Although actually, that is less a ColdFusion feature and more a J2EE server feature that ColdFusion users can take advantage of. ColdFusion MX, after all, is a Java application (deployed as an EAR or WAR, like any other Java application). I've discussed the benefits and the importance of using multiple instances before, but simply put, using multiple ColdFusion instances provides greater security, greater stability, and greater scalability (almost like having ColdFusion installed on multiple physical servers, but all on one server).
The current shipping version of ColdFusion Enterprise supports the use of multiple instances. If you have an existing J2EE server, you can create multiple EAR or WAR files, and can then deploy them (as you would any other Java application). If you do not have an existing J2EE server, the ColdFusion installer can install JRun 4 for you, and in doing so will also create and deploy the first ColdFusion instance so that you can be up and running immediately. But when you want to deploy additional instances, then things get a little tricky for users without experience in J2EE server administration. You'll need to use the J2EE server administration tools to create a new server, run the ColdFusion installer to create the EAR or WAR, expand the files (if using JRun), make tweaks to an XML file, then copy the expanded files into the server folders ... doable, but not exactly a trivial process. (And unfortunately, this is why so many users have yet to deploy multiple instances).
Blackstone should make this a whole lot simpler. (I say "should" because Blackstone is still in beta and stuff could still change between now and when we ship). Blackstone should have the same three installation options that are present in ColdFusion MX 6.1, but selecting the JRun+CF option in Blackstone installs additional administration screens that make the deployment of instances (and even the creation of clusters of instances) as simple as any other ColdFusion administration processes. You'll be able to simply fill in a form and hit a button to create a new instance, without needing to use the JRun management tools or the ColdFusion installer, without needing any XML tweaks, and without even knowing what an EAR or WAR file is.
How could this be used? Consider these use cases:
1) You are deploying a brand new application, one that uses its own data sources and is built by a different development team (who need CF Administrator access), and you want the new application to be safely isolated from your existing production applications. Simply create a new instance, launch the ColdFusion Administrator for that new instance, define the data sources and any other needed settings, copy the code, and you are good to go.
2) You are about to deploy an update to your application code, and need to maintain the existing application as a fall-back, just in case something goes wrong. Simply create a new instance, (you could even create a CAR file using the old instance to save data sources and any other needed configuration, launch the ColdFusion Administrator for the new instance and import the CAR file to import those settings), copy the code, associate your Web server to the new instance, stop the old instance (to prevent resources being used unnecessarily), and you are done. If you then need to roll-back, start the old instance, and reassociate your Web server to it. Clean and simple.
3) You have an existing application that is seeing a spike in load (holiday shoppers maybe), and want an additional server running the same application (so that you can handle a greater load, and also provide failover in the event that a server problem occurs). Simply create a new instance, point to the Java package containing the code and settings used for the first instance, and let ColdFusion do its thing. You'll have a second instance created, configured like the first, and containing the same application as the first. You can then use a second screen to create a cluster (perhaps to enable session sharing between the instances).
You get the idea.
Of course, for those who want more control, JRun will still be installed with its own management software just like it is now, and you can deploy and manage applications just as you can now. But for those of us who simply want to leverage what is undoubtedly the most significant benefit of ColdFusion Enterprise over ColdFusion Standard, Blackstone should make life much simpler.
Macromedia will be hosting a MX Conference in Taiwan on November 9-10, and it looks like I'll be attending. I have no details yet, but will post them as soon as they are available.
A user e-mailed me to ask how to define JRun server instances as Windows services (so that they autostart). In case others need this same information, JRun comes with a utility named jrunsvc that is used for just this purpose. Documentation for jrunsvc can be found at http://livedocs.macromedia.com/jrun/4/Installing_JRun/install5.htm.
An important new tech note at http://www.macromedia.com/support/coldfusion/ts/documents/class_files_loaded.htm explains how to JVM arguments to obtain a listing of all class files that are loaded in the JVM's memory space. This can be useful for debugging class loading conflicts and for analyzing application object usage.
Several months ago I posted an entry about changing the JRun JRE (http://www.forta.com/blog/index.cfm?mode=e&entry=1026). A couple of users have asked me how to change the ColdFusion JRE if using ColdFusion in standalone server mode (with embedded JRun). The instructions are actually, the same, just the path to the jvm.config file is different. The JRE path is stored in {CFMX root}/runtime/bin/jvm.config. To change the JRE, simply edit this file and set java.home to the desired path. Be sure to make a backup of the file first, and you'll also need to restart ColdFusion for the change to take affect.
JRun: http://www.macromedia.com/software/jrun/
Studio (DW, FL, FW, FH): http://www.macromedia.com/go/studioupdates
I recently needed to change the JRE used by JRun (to a newer version). No problem, just stop JRun, remove the old JRE, install the new one and restart JRun. Right? Nope. JRun stores the JRE path, and that needs to be updated to reflect the new JRE location. It took a few minutes to find where this information is stored, so in case anyone else needs this (or for the next time I need it myself), it is in {JRun root}/bin/jvm.config.
