The article at
http://www.adobe.com/go/1e8e9170
is specific to configuring two or more cluster nodes that reside on
separate networks, e.g. 10.0.1.0/24 and 10.0.2.0/24. (The article
doesn't state it, but you can only use unicast peers if your
cluster nodes host a single instance of JRun or multiple instances
of JRun in the same cluster domain. When performing unicast
discovery, JRun looks for all Jini groups and not just the cluster
group.)
Anyhow, that's not your problem. The simplest solution is you
haven't enabled the jrun.servlet.jrpp.JRunProxyService service. I'm
most familiar with the Windows version of JRun, but I'm assuming
the directory structure is similar across platforms. In
<jrun_root>/servers/<name>/SERVER-INF/jrun.xml, set the
deactivated attribute of the jrun.servlet.jrpp.JRunProxyService
service to false and restart JRun. You should now see JRun
listening on the appropriate port. (The default for the first
manually created instance is 51000.) You can limit the proxy
service to a single interface using the interface attribute.
If you have enabled the proxy service, verify your security
settings in <jrun_root>/lib/security.properties. It's usually
best to limit access to specific hosts. Comment out the
jrun.subnet.restriction parameter and set the jrun.trusted.hosts to
the IP address of your web server, e.g. 10.1.0.54.
Forcing all JRun processes/services to listen on a single
interface isn't difficult, but it does require modifying quite a
few configuration files by hand. If you need assistance with that,
I can elaborate.
Configuring the JRun module under Apache is pretty
straightforward. If you're not using virtual hosts, it's very
simple. If you are using virtual hosts, it's still simple, but your
JRun configuration can be virtual host-specific.
On your Apache server, you'll want to create a directory
structure for the JRun module. I'll assume
/opt/jrun/lib/wsconfig/1, but you can use anything you want. Once
the directory structure is created, extract the appropriate JRun
module from wsconfig.jar to the new directory. You're most likely
interested in the Apache 2.0 module,
wsconfig.jar/connectors/apache/intel-linux/prebuilt/mod_jrun20.so.
Let's assume you've extracted the module to
/opt/jrun/lib/wsconfig/1/mod_jrun20.so. Your Apache service account
should have read, write, and execute permissions on the
/opt/jrun/lib/wsconfig/1 directory.
The JRun module configuration is normally appended to your
current httpd.conf file by wsconfig. Here's a sample configuration:
LoadModule jrun_module
"/opt/jrun/lib/wsconfig/1/mod_jrun20.so"
<IfModule mod_jrun20.c>
JRunConfig Verbose false
JRunConfig Apialloc false
JRunConfig Ssl false
JRunConfig Ignoresuffixmap false
JRunConfig Serverstore
"/opt/jrun/lib/wsconfig/1/jrunserver.store"
JRunConfig Bootstrap 10.1.0.70:51000
#JRunConfig Errorurl <optionally redirect to this URL on
errors>
#JRunConfig ProxyRetryInterval 600
#JRunConfig ConnectTimeout 30
#JRunConfig RecvTimeout 30
#JRunConfig SendTimeout 30
AddHandler jrun-handler .jsp .jws .cfm .cfml .cfc .cfr
.cfswf
</IfModule>
You may also want to update your DirectoryIndex directive
with an appropriate index page, e.g. index.cfm.
After the first request to a page handled by the JRun module
is received, the module will query the boostrap server,
10.1.0.70:51000, for a list of cluster peers. If you've configured
your cluster correctly, a line similar to following will be written
to /opt/jrun/lib/wsconfig/1/jrunserver.store:
proxyservers=10.1.0.70:51000;10.1.0.71:51000
You can create/edit this file manually as well.
Unfortunately, the bootstrap option only accepts one server. If
your bootstrap server is down, the JRun module will use the values
in jrunserver.store directly, if the file exists.
Here's a complete list of JRun module options:
metrics *
debugger *
ssl *
verbose
traceflags
serverstore
bootstrap
errorurl
apialloc
ignoresuffixmap
proxyretryinterval
connecttimeout
recvtimeout
sendtimeout
sslcalist
Options flagged with an asterisk can only be configured at
the Apache server level. All other options can be configured at the
server level and/or the virtual host level. The usage of these
options is in the JRun documentation, and the JRun module source
code is included in wsconfig.jar. Keep in mind that versions of the
JRun module shipped prior to ColdFusion 8 were coded to assign the
connecttimeout and sendtimeout options to the socket connection
timeout. Whichever option appeared last in your configuration ended
up as the final value. This has been fixed in ColdFusion 8 and
presumably the next release of the JRun updater.
I think that's a good start. If you need more information or
can't find what you need in the JRun or ColdFusion documentation,
let me know.
If you're looking for resiliency, I highly recommend
expanding your configuration to include a second web server and a
hardware load-balancer (preferably one that supports redudancy via
multiple paths and devices, e.g. devices from Cisco, F5, or Foundry
Networks). Often, however, running Apache on the ColdFusion
server(s) provides adequate performance, and round-robin DNS
records coupled with the ability to update DNS quickly in the event
of a failure may be all you need for load-balancing and
failover.
10
Replies
AdChoices