...
The Dispatcher will loadbalance requests from new users between the defined servers – once a user has gotten a server assigned to him, all future requests from that user will reach the same server while it is up – if it goes down, another server will be selected, and all future requests will go to that one.
Clustering
The dispatcher is easy to cluster, simply setup multiple dispatcher servers (they do not need to know about each other, but they do need to share the same application servers in the configuration).
In front of the dispatchers, setup a load balancer, preferably a hardware load balancer with built-in support for hardware SSL handshaking. Set the load balancer to use random or round-robin balancing, there is no need to set it up for session affinity, such as by IP address or similar, since the dispatchers will make sure that the same user reaches the same application server, regardless of which dispatcher receives the request.
The dispatcher will do load balancing and failover towards the configured application servers. Each configured server has a logical name, which will be placed in a session cookie sent to the client – when a dispatcher receives a new request, it will forward it to the appropriate application server, if it is currently up. If it is down, another server will be selected for the user.
New users will be sent to a random server, selected from the list of application servers that are currently responding to requests.
Reasons for clustering the Dispatcher include both failover and performance – especially if the Dispatcher has to handle software SSL, the CPU overhead can be enormous (a quick rule of thump says that you need 5 times the number of servers if you run SSL, than the number you need to run unencrypted). Note that the SSL overhead can be greatly reduced by using dedicated hardware to handle the SSL handshakes.
Ping URLs
When loadbalancing between multiple servers, it is very important to have a correctly functioning ping URL defined – this URL is periodically requested by the dispatcher to verify that the application is still up. If it returns anything other than the HTTP response code “200 OK” then the server is assumed to be down, and it will no longer receive new requests.
...
Restrictions and limitations:
Attribute | Explanation |
RewriteLogLevel | Specified as int, lean-ups as: <= 1 – FATAL, 2 – ERROR, 3 – INFO, 4 – WARN, >= 5 DEBUG |
RewriteLog | SYSOUT, SYSERR, log4j, commons (if not set log4j logging will be used) |
RewriteRule | Supported but note: Certain flags not supported:
|
RewriteBase | Not supported |
RewriteLock | Not supported |
RewriteMap | Not supported |
RewriteOptions | Not supported |
Examples
This as an example of a few rules as specified in the configuration:
...