This section describes how to use the various areas of the PortalProtect Dispatcher, and gives various examples on how to use it.

Load

...

Balancing

You can use the Dispatcher for loadbalancing load balancing between multiple application servers running the same version of an application.

This is done simply by adding more servers to the “targetservers” or “alternateserver.xxxx.targets” configuration entry – see the dispatcher configuration section for details on how to do it.

The Dispatcher will loadbalance load balance 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.

...

The dispatcher is easy to cluster, simply setup multiple set up 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 set up 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.

...

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 thumb 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 setting up load balancing 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.

...

 Usually, you will set the ping URL to point to a servlet that checks backend database connections and other resources, and only returns “200 OK” if it is able to serve requests successfully – this means that if you have multiple mirrored servers, and one looses loses the connection to its database, then the other servers will receive all the requests until the connection is up again.

...

It is quite easy to dispatch requests to multiple different applications – the ones defined in the “targetservers” can be considered to be the default application – i.e. if no other defined rules selects another server, then the request will go the the server defined in “targetservers”.

...

There are a couple of different ways of protecting URLs – the Dispatcher will always call isURLAllowed() in the Agent, and it’s behaviour its behaviour can be controlled 100% by the implementation in the Validator plugin within the Agent.

...

The dispatcher has previously stored information in the session about which applicationserver (in a cluster) was selected for a particular user, and which dispatchergroup the applicationserver belonged to – the session controller will now sort this out so it ends up with a list of applications within a list of dispatchergroups that need to be “pinged” to keep the http session alive.

It will then devide this divide this into chunks of a few thousand users and divide the work of actually making the requests up between any available dispatchers within a dispatcher group.

...