You must understand the SPO to perform problem determination and diagnosis. The following graphic shows the internal control structures used in the SPO.

The major components in the OpenROAD Server Pooler are:

These components control the operation and behavior of the SPO. Major events are associated with the creation, destruction, starting and stopping of these components. Descriptions of each of these components follows.

Each OpenROAD Server client that creates an instance of the RemoteServer class will have a CSPO created in the SPO. The client surrogate represents an individual client. The TotalClients field in the "SNAPSHOT: DispatcherMgr" represents the total number of currently connected clients to the SPO.

The Dispatcher Manager is responsible to assign each client to a dispatcher based on the application signature that the client passed in the Initiate method. The DispatcherMgr also creates new dispatchers. The DispatcherMgr periodically destroys dispatchers that have no clients assigned and have been idle for a configurable timeout period.

After a client has been assigned to a dispatcher, all method requests from the client are handled directly by the dispatcher. There is only one instance of a DispatcherMgr in the SPO.

The Server Pooler Controller is an OpenROAD Server client that starts and stops the SPO. When the Controller client creates a RemoteServer class instance, COM or DCOM launches the SPO. The SPO will run as long as the Controller client is active.

When the Controller process (orsposvc or orspostart) shuts down as usual, it sends a shutdown message to the SPO, and the SPO will begin its normal shutdown processing. If the Controller terminates abnormally or is killed, COM will notify the SPO and the SPO will shut down.

The Configurator encapsulates the access of all OpenROAD Server configurable options for the various components that make up the SPO. The SPO consults the Configurator whenever a current value for a configurable option is needed. The Configurator accesses the JSON configuration file to obtain this information and provides it to the requestor.

Optionally, the ASO slave will also access the JSON configuration file when ASNs are used. The implication is that when ASNs are being used, the SPO and ASO must be launched on the same machine. (The ASO slave does not use the Configurator to access the JSON configuration file.)

The Server Manager is responsible for ensuring internally consistent and reasonable values for all options. The Configurator only performs minimal sanity checks. The Configurator initializes before the event log. There is only one instance of the Configurator in an SPO.

The Configurator reads the values stored in the JSON configuration file when the SPO process initializes. It does not access this information again until the SPO process is restarted. If the Server Manager makes changes to this information, those changes will not take effect until the SPO process is restarted.

For more information on SPO logging, see OpenROAD Server Pooler Event Log.

Each dispatcher handles Call4GL/JsonRpcRequest requests for a specific application signature. It manages a configurable number of slaves and distributes the incoming calls between slaves by a simple load balancing scheme.

Each dispatcher is assigned an identifier when it is created. This identifier is unique for the lifetime of the SPO process. Each dispatcher maintains a count of clients that are currently bound to the dispatcher.

An ASO Slave Manager represents one ASO slave process in the SPO. A slave does not necessarily always have a connection to an actual ASO. (ASOs can time out and be stopped. The ASO process will exit to release resources but the ASO Slave Manager will continue to be active.) When calls are queued to a slave and there is no active ASO slave process, a new ASO will be started automatically so long as there were no previous errors in the ASO.

Each slave is assigned an identifier when it is created. This identifier is unique for the lifetime of the SPO process.