Now, I'm going to preface this with a note. If you multiple websites (eg multiple domains), you are in a much better position than I am. There are caveats to watch out for with multiple instances for just a single site, which will be detailed later on.
My day job is working as a government contractor, and the clients in our shared environment are only given virtual directories off the main domain root. And we're talking about about 50 total applications.
After (finally) getting FusionReactor installed in-house, we have started finding a trend about which applications have been causing problems with our environments. Since we were already using CF installed as J2EE applications, we decided to pull the trouble application into its own instance.
Now, we don't have much clout when it comes to making changes within the environments, so moving this one site into its own domain would/will require lots of paper work, approvals, and time. However, customers don't won't to hear an answer like that, so we came up with a way to work within the system, but didn't require moving a mountain.
So, the steps to get you where you're going:
- First, I usually have a default cfusion-ear file waiting to roll. However, making a copy of your existing cfusion-ear works fine as well. Create a new folder within your {jrunroot}/servers directory for this new instance. We'll call it instance2. Copy the cfusion-ear file into this directory.
- Log into the JMS, or click the ColdFusion Enterprise Manger if you have CFMX 7 installed in multiserver mode. Create a new instance and give it the same name as the folder you just created. So, instance2 for example.
- If this is part of a cluster (mine are), create an instance on the other machine(s). CAUTION: Make certain that each instance, if it's to be part of a cluster, MUST have a unique name. I did not know this until it bit me and caused all kinds of replication issues.
- If this is part of a cluster, create the cluster and add the instances. Otherwise, skip this step.
- Start IIS admin (I haven't tested this on apache yet) and create a new website. Doesn't really matter where it points to, or the port that it exists on. This has been tested on IIS 5/6.
- Start up the JRun website configurator. I generally call the jar file directly as the default JVM is 1.3 on our systems, where the ColdFusion JVM is 1.4 which is required. Add a new site, and select the instance/cluster you just created and map it to the website you just created. Make sure to check to the box to install the ColdFusion connector.
- You now have a new numbered directory in {jrunroot}/lib/wsconfig. You can now map the virtual directory to use this connector instead of the default connector. Open the properties of the virtual directory, select Configuration from the Directory tab. If you're using IIS 6, you can merely change the filter in one spot. If you're using IIS 5, you need to change the filter for each CFM type file.
Restart IIS and you should be good to go. So how do you know it's working? Well... you could install SeeFusion or FusionReactor. You could check the HTML headers to verify the JSESSIONID. The first four characters should match the {jrunroot}/servers/{instance}/server-inf/connector.properties. You could put code into your application that makes a call to serviceFactory that reports the instance information. And on and on.
So, the caveats:
- Doing this WILL break CFCHART. In fact, anything that makes a call to /CFIDE that is interpreted by the web.xml file will be affected. There is a solution to this, and it will be the subject of my next blog post
-
- You might have issues if you use session replication if the instances are in clusters. Let me give you an example. User visits your www.somesite.com/whatever. There is a link from there to the site in its newly created instance. The JESSIONID from the /whatever site still exists. Uh oh. You'll receive errors about failed session replication in the logs, and the user will get round-robined across the new cluster. This is especially a pain if there is any session information holding user values. The information will not be propagated across the cluster, and the users session will appear to be timed out. The only solution I've found to this is to either destroy the JESSIONID cookie, or pull the instance into its own website.