Clearcase : About ClearCase server processes

albd_server process
When a client program needs access to a service (a VOB or view server, for example) on a ClearCase server host, it uses a remote procedure call (RPC) to send a request to the albd_server process on that host. The albd_server starts the requested service if it is not already started, and provides the service’s port number to the client. Thereafter, the client communicates directly with the service.

The albd_server handles a variety of tasks on hosts configured to support local VOBs and views:
•Starting and stopping other Rational ClearCase services as needed.
•Setting up network communications between Rational ClearCase clients and servers.
•Managing execution of tasks run by the Rational ClearCase scheduler.
•Responding to requests for registry information on a Rational ClearCase registry server host.
•Responding to requests for licenses on a Rational ClearCase license server host. (Rational ClearCase LT does not use the albd_server in this way.)

admin_server process
The ClearCase administration server (admin_server) is invoked as needed by the host’s albd_server process. This short-lived server performs miscellaneous administrative support functions.
The admin_server handles the following tasks:

* Retrieving the server log files displayed by the getlog command and the Rational ClearCase Administration Console.
* Retrieving and changing the Rational ClearCase properties on the local host when requested by the Rational ClearCase Administration Console.
* Moving registry files and reconfiguring clients if the host is a backup registry server.

credmap_server process
The credentials mapping server,credmap_server, runs on any Rational ClearCase host that is configured to support local VOBs and views. This server handles credentials mapping in environments where users access a common set of VOBs and views from computers running different supported operating systems.

view_server process
A view_server is a long-lived process that manages activity in a particular view. A view_server is started by the host’s albd_server process whenever a client requests access to a view. A view_server remains active until it is terminated by a cleartool endview –server command, a system shutdown, or an operating system command that terminates the view_server process.

When it begins execution, a view_server reads configuration information from the .view file in the view-storage directory. Values in this file are established by mkview, chview, and similar commands. Do not modify this file with a text editor.

vob_server process
For each VOB, a long-lived vob_server process runs on the VOB host. The vob_server manipulates data in the VOB storage pools in response to requests from client processes.
The vob_server is the only process that creates or deletes VOB data containers; only the VOB owner or a privileged user can modify VOB data containers and storage pools. For more information, see The VOB storage directory.
A vob_server process is started as needed by thealbd_server process. It remains active until any of the following events occur:

* The VOB is removed with the rmvob command.
* Rational® ClearCase® is stopped on the VOB server host.
* The VOB server host is shut down and restarted.

When it begins execution, the vob_server reads configuration information from the file vob_server.conf in the VOB storage directory. Values in this file are established by the vob_snapshot_setup utility and other commands. Do not modify this file.

db_server process
The db_server processes manage VOB database transactions on a host in response to requests from client programs. Because client programs cannot access VOB databases directly, they must send database transaction requests to a db_server process when they must create, read, or modify VOB data or metadata.

Each db_server process services a single client at a time, but can operate on any number of VOBs. A client establishes a connection to a db_server with the help of the albd_server on the VOB host. If necessary, the albd_server starts a new db_server process to handle a request. The connection is broken when the client exits or becomes idle (stops requesting database transactions for an extended period). At that point, the db_server becomes available for use by another client. After a period of idleness, an unconnected db_server is terminated by its host’s albd_server process.

vobrpc_server process
Each VOB server host runs one or more vobrpc_server processes for each of its VOBs. Each vobrpc_server process handles requests from view_server processes throughout the network. These requests can generate both metadata (VOB database) and file-system data (storage pool) activity. The vobrpc_server process accesses the VOB database in the same way as a db_server; it forwards storage pool access requests to the vob_server.

The vobrpc_server processes are started by thealbd_server process, which also routes new requests to the least-busy servers and terminates unneeded vobrpc_server processes when the system is lightly loaded.

lockmgr process
On Windows hosts and some Linux hosts that are VOB servers, a lock manager arbitrates transaction requests to all VOB databases on that host. When a process requests VOB data, the lockmgr process or the VOB's db_server grants or prohibits access to that data. If the data is available, the transaction proceeds immediately: the data is read or written, and output is returned to the calling program. If the data is unavailable (locked because another caller has been granted write access to the data), the caller waits until the lockmgr or db_server grants access to the data.

rwp process
The IBM Rational Web Platform rwp provides application support for the Rational® ClearCase® Remote Client and Rational ClearCase Web Client.
RWP servers are usually configured during installation and need no further administrative attention unless special configurations (for example, a configuration to support access by proxy) are required. A Rational ClearCase community may have one or more rwp servers.