IIS communicates with JRun and not ColdFusion specifically,
so it's possible to connect to as many different JRun instances as
you want, regardless of the version of ColdFusion being hosted by
JRun.
First, let's have a quick overview of the IIS-related files
in wsconfig.jar. The directory structure of the wsconfig.jar
archive did not change between ColdFusion MX 7.0.2 and ColdFusion
8. I recommend using the files from the archive shipped with
ColdFusion 8.
connectors\installers\intel-win\prebuilt\jrunwin32.dll
jrunwin32.dll exports functions used by wsconfig to configure
and manage IIS. If you're not going to use wsconfig to manage your
IIS configuration, you don't need this file.
connectors\isapi\intel-win\prebuilt\jrun.dll
jrun.dll is the ISAPI filter and extension library used by
IIS 5.1 and earlier. It provides both global filtering, configured
at the server level, and application mappings, configured at either
the site or application (directory or virtual directory) level.
Defaut application mappings can also be configured at the server
level.
connectors\isapi\intel-win\prebuilt\jrun_iis6.dll
jrun_iis6.dll is the ISAPI extension library used by IIS 6.0
and later. It provides application mappings configured at either
the site or application (directory or virtual directory) level.
Default application mappings can also be configured at the server
level.
connectors\isapi\intel-win\prebuilt\jrun_iis6_wildcard.dll
jrun_iis6_wildcard.dll is the ISAPI extension library for
wildcard application mappings used by IIS 6.0 and later. It
provides wilcard application mappings configured at either the site
or application (directory or virtual directory) level. Default
wilcard application mappings can also be configured at the server
level. Wildcard application mappings in IIS 6.0 are similar to
filters in IIS 5.x; however, wildcard application mappings can be
more granular in scope and do not hinder IIS performance as filters
did in the past.
Wsconfig performs the following steps when configuring an IIS
web site:
1. Creates the lib\wsconfig directory.
2. Creates the wsconfig.properties file.
3. Extracts jrunwin32.dll to lib\wsconfig.
4. Creates the lib\wsconfig\1 directory. (The significance of
the numbered directory will be explained later.)
5. IIS 5.x: Extracts jrun.dll to lib\wsconfig\1.
6. IIS 6.0: Extracts jrun_iis6.dll to lib\wsconfig and
jrus_iis6_wildcard.dll to lib\wsconfig\1.
7. IIS 5.x: Creates the lib\wsconfig\1\jrun.ini file.
8. IIS 6.0: Creates the lib\wsconfig\jrun_iis6.ini file.
9. IIS 6.0: Creates the lib\wsconfig\1\jrun_iis6_wildcard.ini
file.
10. Configures IIS.
From this point forward, we'll focus on IIS 6.0.
The wsconfig.properties file is used by wsconfig to keep
track of configured web sites. The numbers in the first column of
this file correpsond to the numbered directories in lib\wsconfig. A
sample IIS configuration looks like this:
1=IIS,1,false,""
1.srv=localhost,"cfusion"
1.cfmx=true,<null>
The first key/value pair contains information about the web
server you opted to configured. The first field in the value is the
web server, IIS in this case. The second field in the value refers
to IIS instance 1 and corresponds to the web site you selected from
the IIS Web Site drop-down list. The instance number is listed in
Indentifier column in Internet Information Services (IIS) Manager
when the Web Sites node is selected in the tree view. An instance
number of 0 corresponds to the All option in the IIS Web Site
drop-down list and all changes will be made at the server level.
The third field in the value notes whether or not you opted to use
the ISAPI filter under Advanced Settings. This field is always
false in IIS 6.0. The last field in the view is a comma-delimited
list of file extensions to use in application mappings. An empty
value notes that the default file extensions should be used.
The next key/value pair, X.srv, contains information about
the JRun instance. The fields correspond to the JRun Host and JRun
Servers options you selected.
The last key/value pair, X.cfmx, corresponds to the
"Configure web server for ColdFusion MX/8 applications" option.
(There is a gap of my knowledge of wsconfig at this point. I don't
know what the <null> in the second field represents. When the
first field is false, the second field is not populated.)
As you configure additional web servers, new directories are
created under lib\wsconfig with corresponding sections in
wsconfig.properties. Adobe's manual configuration instructions
typically include creating the wsconfig.properties file; however, I
don't believe the file is necessary for the connector to function.
See the bootstrap value discussed further down.
The jrun_iis6.ini file contains two keys, verbose and
errorurl. Setting the verbose key equal to true enable verbose
logging in jrun_iis6.dll. Setting the errorurl key to an
appropriate URL causes the connector to redirect to a specific page
on errors, which is useful if you want to present your users with a
warm and friendly failure notification rather than an internal
server error.
The jrun_iis6_Wildcard.ini file contains most of the settings
we'll need to modify to support multiple instances of ColdFusion. A
default jrun_iis_wildcard.ini file looks like this:
verbose=false
serverstore=D:/JRun4/lib/wsconfig/1/jrunserver.store
bootstrap=127.0.0.1:51000
apialloc=false
ssl=false
#errorurl=<optionally redirect to this URL on errors>
#proxyretryinterval=<number of seconds to wait before
trying to reconnect to unreachable clustered server>
#connecttimeout=<number of seconds to wait on a socket
connect to a jrun server>
#recvtimeout=<number of seconds to wait on a socket
receive to a jrun server>
#sendtimeout=<number of seconds to wait on a socket send
to a jrun server>
Setting the verbose key to true enables verbose logging in
jrun_iis6_wildcard.dll.
The serverstore key contains the path to the cached JRun
proxy service hosts and ports. More on this later.
The bootstrap key contains the JRun proxy service host and
port used to initialize the connector. This is the magic key that
determines which instance of ColdFusion will be used by the
connector. Once retrieved during the bootstrap process, the list of
JRun proxy service hosts and ports are written to the file
specified by the serverstore key.
The apialloc key corresponds to the "Enable native OS memory
allocator" option in Advanced Settings.
The ssl key determines whether or not communication between
JRun and the connector is encrtyped using SSL. This is outside the
scope of this post.
The errorurl key has the same meaning as the errorurl key in
the jrun_iis6.ini file.
The proxyretryinternal, connecttimeout, recvtimeout, and
sendtimeout keys do exactly what the comment say they do. The
values of these keys should be optimized for your environment.
The main values of interest are serverstore and bootstrap.
The connector refers to these values to connect to a JRun server.
Upon the first connection attempt, the connector reads the value of
the bootstrap key. It then attempts to connect to the host and port
specified. If the connection is successful, the connector will
query the JRun server for a list of valid peers. If you've
configured a cluster, the JRun server will return an array cluster
peers in ip:host format, where ip is the primary IP address of the
JRun server. For single instances, a single ip:host value is
returned. The list of peers is then cached in the file specified by
the serverstore key, typically jrunserver.store.
The jrunserver.store file contains a single key,
proxyservers. A sample proxyservers key looks like this for a
single-instance environment:
proxyservers=10.0.0.1:51000;
For clustered instances of JRun on the same host, the
proxyservers key may look like this:
proxyservers=10.0.0.1:51000;10.0.0.1:51001;
For clustered instances of JRun on different hosts, the
proxyservers key may look like this:
proxyservers=10.0.0.1:51000;10.0.0.2:51000;
Any combination of instances is possible, assuming all
instances are part of the same cluster. It's possible to have the
connector use multiple non-clustered instances of JRun, and if your
application is entirely stateless, this may be a valid option for
you. In fact, you configure a cluster using unicast peers, all
instances of JRun on the unicast peer will be added to the
proxyservers key. This is contrary to the way session replication
operates in JRun and is most likely a bug in JRun's Jini
implementation. (I've posted about this previously, but I haven't
received a reply from Adobe.)
(cont)