As an example of how load balancing works, suppose you have an application called MyApp and you have configured WebObjects to run two instances of MyApp on the host toga and two instances on the host tutu. When a user types this URL:
http://toga.acme.com/cgi-bin/WebObjects/MyAppthe WebObjects adaptor looks for an instance of MyApp on the host toga. If it finds an instance and the instance is ready to receive requests, the adaptor sends the request to that instance. If both of the instances of MyApp on toga are busy, it accesses an instance on the host tutu.
Use the Monitor application to create multiple new instances of an application for load balancing. See "Creating Application Instances" on for details.
When you create multiple application instances, you are creating the public configuration file NEXT_ROOT/Library/WebObjects/Configuration/WebObjects.conf. When the adaptor receives an HTTP request for an application, it first (in its initial mode) checks WebObjects.conf for an application instance that is accepting connections and forwards the request to it. The section "WebObjects HTTP Adaptors" describes in some detail both the public configuration file and the adaptor modes involved in load balancing.
Monitor always assigns a unique number to each application instance, even if it is running on a different host. It does this so that it can recover a crashed instance for you. If an instance dies, Monitor can try to recover it by launching it on another host. Because of this, instance numbers must be unique across hosts.
Table of Contents
Next Section