Configuring a Dependent Spawner

Dependent spawners are spawners that assist the main, or master spawner in handling client requests for an IOM server. When you set up and invoke dependent spawners, client requests rotate among master spawners and their dependent spawners on a round-robin basis. This configuration provides more efficient handling of multiple user requests.

Dependent spawners can run on the same host machine as the master spawner, or they can run on other host machines in the network. In addition, a dependent spawner can support more than one master spawner as long as the master spawners all reside in the same domain.

A sample dependent spawner configuration is shown in the diagram below.

In this example, five dependent spawners are supporting two IOM servers. The dependent spawners are spread among three different host machines.

Defining a Dependent Spawner

To define a dependent spawner, you must create a sasDependentSpawner object using either IT Administrator or a configuration file. The object's attributes are similar to those used for a master spawner. For a complete list of attribute definitions, refer to Attributes for sasDependentSpawner. For the dependent spawner to work correctly, you must follow these guidelines:

• Assign a domain name that matches the domain name of the IOM server and master spawner that the dependent spawner is to support. If the dependent spawner is to support multiple IOM servers and master spawners, they must all have the same domain name. If the IOM server(s) and master spawner(s) do not have domain name attribute(s), do not define a domain name attribute for the dependent spawner.

• Assign a logical name that matches a logical name that is associated with each IOM server and master spawner that the dependent spawner is to support. If an IOM server or master spawner has more than one logical name, specify at least one of the names. If the dependent spawner is to support multiple IOM servers and master spawners, specify all necessary logical names.

• Assign a machine DNS name for each host on which the dependent spawner may execute. The host(s) may or may not be the same machine(s) on which the master spawner(s) and server(s) reside.

• If you use a configuration file, it is recommended that you place the dependent spawner definition in the same configuration file as the master spawner and server definitions. The dependent spawner uses these definitions to complete its configuration.

For an example of the metadata needed to set up a dependent spawner, refer to the Dependent Spawner configuration file example.

Invoking (Starting) a Dependent Spawner

To start a dependent spawner, use the -dependent invocation option with the spawner command. This option may be abbreviated as -dep.

When a dependent spawner is started, it determines which master spawners it is supporting. It then connects to those spawners' master ports. The connection process notifies the master spawner(s) that the dependent spawner is available to handle client requests.

To connect with the master spawner(s), the dependent spawner performs the following detailed steps:

• First, the dependent spawner determines which host it is running on. It then searches the LDAP directory (or configuration file) for the first sasDependentSpawner definition with that host defined as its sasMachineDNSName.

• The dependent spawner then searches for matching server definitions based on the sasDependentSpawner domain name and logical name attributes. A server is considered "matching" only if the following requirements are met:

  • The dependent spawner's domain name must match the server's domain name. If the dependent spawner has no domain name attribute, the server's domain name must not have a domain name attribute.

  • At least one of the dependent spawner's logical names must match one of the logical names assigned to the server.

  • The server's definition must include either a master port (sasMasterPort) or a master service (sasMasterService).

  • The server must have a protocol (sasProtocol) of bridge.

• The dependent spawner then determines the host machine for each matching server. Using these host names, it searches for all spawners with the same host name, domain name, and logical name. (If the dependent spawner does not have a domain name attribute, it searches for server definitions that do not have domain name attributes.) These are the "master spawners" for the dependent spawner.

• The dependent spawner creates a listen socket for each server definition and binds each socket to "any" available port.

• The dependent spawner scans each master spawner definition to determine its master port, and then connects to it. The connecting process alerts the master spawner that it has a dependent spawner.

  Note: If the dependent spawner is unable to contact a particular master spawner, it attempts the connection again within three minutes. The attempts are repeated until all of the connections are established. If you wish, you can initiate a connection attempt by issuing the start administrator command. The list administrator command provides information about the dependent spawner's connection status.

How Dependent Spawners Work

When a client connects to a master spawner's listen port, the master spawner either processes the request itself or redirects the request to an available dependent spawner. The master spawner uses a round-robin scheduling algorithm to determine which spawner should handle the next request. This process works as follows:

• When the first client call comes in, the master spawner (1) handles the request and (2) sets a pointer indicating that the next request should be handled by a dependent spawner.

• When the second client call comes in:

  • The master spawner (1) notifies the client that it should request a service from the dependent spawner and (2) gives the client the dependent spawner's host (machine) name and listen port.

  • The client uses this information to redirect the call to the dependent spawner.

  • The master spawner sets the pointer to the next dependent spawner in the list (or back to itself) to handle the next client call.