Multiple Server Configurations

ColdFusion is a J2EE application. The ColdFusion Enterprise Edition is deployable on multiple J2EE application server instances. Supported J2EE application servers include Macromedia JRun, BEA WebLogic, IBM WebSphere, and Sun Application Server. Running ColdFusion in multiple instances on J2EE application servers provides scaling through application isolation and server clustering/failover. You can combine multiple server instances with multi-homed Web servers to provide complete application and Web site isolation.

NOTE

For information on configuring application isolation with multi-homed Web servers, see "Web Server configuration for Application Isolation" in the Configuring and Administering ColdFusion manual at http://livedocs.macromedia.com/coldfusion/7/htmldocs/00001773.htm.

ColdFusion MX 7 Enterprise Edition in Multiserver configuration introduces the ability to configure JRun server instances and automatically deploy an instance of the ColdFusion MX 7 application server to those instances from within the ColdFusion Administrator. Administrators can combine this feature with the J2EE Archives feature to deploy packaged ColdFusion applications that contain the application server, application files (.cfm, .cfc, .cfr, etc.), and server settings (data source definitions).

NOTE

Chapter 6, "Deploying Applications," provides more details on packaging ColdFusion application servers as J2EE Archives. Chapter 4, "Scaling with J2EE," discusses configuring multiple instances with the ColdFusion Instance Manager.

Running multiple instances of ColdFusion on J2EE application servers provides the following security benefits:

• Each ColdFusion instance is isolated so that each has dedicated server resources, including JVM, simultaneous requests, memory, caching, data sources, and so on.

• Applications can be isolated to leverage individual server instances and individual Web server instances.

• Application isolation prevents problems (bottlenecks, memory leaks, and the like) in one application from affecting in other applications.

• Application isolation increases sandbox security by extending restrictions to an application instance.

• Clustered instances provide failover, which can help maintain the user session integrity for sensitive data such as shopping carts.

Configuration Issues for Multi-homed Web Servers

Most ISPs operate in a multi-homed environmenta server containing multiple virtual Web server instances, each with a separate Web root. This is also known as multi-hosting; a server hosts multiple domain names on a single IP address. In these configurations, each virtual server has a different Web root and domain name, but a single ColdFusion server answers requests for all virtual servers. When configuring ColdFusion in these environments beware of the following issues, which are discussed in the sections that follow:

• Running the stand-alone ColdFusion Web server

• Cached Web server paths enabled

• ColdFusion Administrator access

• Access to the cfform.js file

NOTE

Most of the information in this section describes issues with multi-homed configurations affecting ColdFusion MX 6.0. These issues were corrected in the 6.1 release. The information in this section may prove useful for administrators upgrading from ColdFusion MX 6.0 to 7, or who have a misconfigured 6.1 installation.

Problems with the Stand-Alone Web Server and Web Server Path Caching

The ColdFusion MX 6.0 stand-alone Web server ran by default after an install. ColdFusion MX 6.1 fixed this issue; however, it is still considered a best practice to install ColdFusion using the stand-alone Web server, and then enable external Web server support after completing the Configuration Wizard.

The stand-alone Web server runs on port 8500 by default. Keep in mind that running the stand-alone server in addition to your production Web server adds overhead and potential security risks on port 8500.

TIP

If it detects an existing ColdFusion server bound to port 8500, the ColdFusion MX 7 stand-alone Web server may bind to port 8501. This allows both versions to run simultaneously. If port 8501 is taken, the stand-alone server will continue to search incrementally until it finds an open port.

ColdFusion MX 6.0 also enabled template path caching by default to optimize performance. On multi-homed servers, template path caching may cause the incorrect display of all templates with relative paths similar to their respective Web server roots. For example, ColdFusion will cache the first request for http://www.mysite.com/products/index.cfm, and any subsequent calls to http://www.yoursite.com/products/index.cfm will display the cached /products/index.cfm page results for www.mysite.com because the relative paths are similar. This problem was corrected in ColdFusion Updater 2, but administrators should still be wary of this issue.

TIP

See the Macromedia ColdFusion Release Notes (http://www.macromedia.com/support/documentation/en/coldfusion/releasenotes.html) for more information on these and other issues.

You can shut down the stand-alone Web server and disable Web server path caching either in the cf_root\runtime\servers\coldfusion\SERVER-INF\jrun.xml (Server configuration) or in jrun_root\servers\coldfusion\SERVER-INF\jrun.xml (Multiserver configuration). Use the following steps to modify the jrun.xml file:

1.	Back up the jrun.xml file
2.	To turn off the stand-alone Web server, navigate to the WebService service class declaration and set the deactivated attribute to true: <attribute name="deactivated">true</attribute>
3.	To disable Web server path caching, navigate to the ProxyService service class declaration and ensure the cacheRealPath attribute to false: <attribute name="cacheRealPath">false</attribute>
4.	Stop and restart ColdFusion

Issues with ColdFusion Administrator Access

The ColdFusion Administrator should only be accessed from one Web server instance. This keeps administration simple and helps augment the ColdFusion Administrator security. Because all ColdFusion Administrator instances modify the same configuration files, having multiple instances can cause unforeseen problems leading to server instability or failure. However, should access to the ColdFusion Administrator be required from virtual sites, create a virtual mapping to the originally installed CFIDE directory. You can also create local CFIDE directories for individual virtual servers and copy to them the code from the original CFIDE; this does, however, add an additional administration step of keeping the code in sync.

NOTE

Access to ColdFusion Administrator functionality is now available via the ColdFusion Administrator API in CFMX 7. See Chapter 11, "Using the Administration API," for details.

TIP

You can use the Web Server Configuration Tool's -cfwebroot option, to allow access to the CFIDE directory under the specified Web root when configuring virtual server integration with ColdFusion.

Access to the cfform.js File

The cfform.js contains the client-side JavaScript used for <cfform> validation. The default location for this file is CFIDE/scripts. If this folder is not available to all virtual servers, the <cfform> validation will fail. If application logic in any of the virtual servers will use <cfform>, take one of the following actions:

• Map a virtual directory from the virtual server instance to the original CFIDE/scripts folder.

• Copy the original CFIDE/scripts folder to the virtual server's Web root.

• Specify the location for the cfform.js file in the ScriptSrc attribute for every <cfform> tag used.