On-demand activation occurs when an Ice client requests the endpoints of one of the server’s object adapters via a locate request (see
Section 35.3.1). If the server is not active at the time the client issues the request, the node activates the server and waits for the target object adapter to register its endpoints. Once the object adapter endpoints are registered, the registry returns the endpoint information back to the client. This sequence ensures that the client receives the endpoint information
after the server is ready to receive requests.
When using session activation mode, IceGrid requires that the server be allocated; on-demand activation fails for servers that have not been allocated. (See
Section 35.11 for more information on server allocation.)
The session activation mode recognizes an additional reserved variable in the server descriptor,
${session.id}. The value of this variable is the user ID or, for SSL sessions, the distinguished name associated with the session.
Once a server is activated, it remains running indefinitely (unless it uses the session activation mode). A node deactivates a server only when explicitly requested to do so (see
Section 28.17.6). As a result, server processes tend to accumulate on the node’s host.
One of the advantages of on-demand activation is the ability to manage computing resources more efficiently. Of course there are many aspects to this, but Ice makes one technique particularly simple: servers can be configured to terminate gracefully after they have been idle for a certain amount of time.
A typical scenario involves a server that is activated on demand, used for a while by one or more clients, and then terminated automatically when no requests have been made for a configurable number of seconds. All that is necessary is setting the server’s configuration property
Ice.ServerIdleTime to the desired idle time. See
Appendix C for more information on this property.
For a server activated in session activation mode, IceGrid deactivates the server when the session releases the server or when the session is destroyed.
On Unix platforms you can activate server processes with specific effective user IDs, provided that the IceGrid node is running as root. If the IceGrid node does not run as root, servers are always activated with the effective user ID of the IceGrid node process. (The same is true for Windows—servers always run with the same user ID as the IceGrid node process.)
The user attribute of the
server descriptor specifies the user ID for a server. If this attribute is not specified and the activation mode is not
session, the default value is
nobody. Otherwise, the default value is
${session.id} if the activation mode is
session.
Since individual users often have different account names and user IDs on different machines, IceGrid provides a mechanism to map the value of the
user attribute in the
server descriptor to a user account. To do this, you must configure the node to use a user account mapper object. This object must implement the
IceGrid::UserAccountMapper interface:
exception UserAccountNotFoundException {};
interface UserAccountMapper {
string getUserAccount(string user)
throws UserAccountNotFoundException;
};
The IceGrid node invokes getUserAccount and passes the value of the
server descriptor’s
user attribute. The return value is the name of the user account.
IceGrid provides a built-in file-based user account mapper that you can configure for the node and the registry. The file contains any number of user–account-ID pairs. Each pair appears on a separate line, with white space separating the user account from the identifier. For example, the file shown below contains two entries that map two distinguished names to the user account
lisa:
You can specify the path of the user account file with the IceGrid.Registry.UserAccounts property for the registry and the
To configure an IceGrid node to use the IceGrid registry file-based user account mapper, you need to set the
IceGrid.Node.UserAccountMapper property to the well-known proxy
IceGrid/RegistryUserAccountMapper. Alternatively, you can set this property to the proxy of your own user account mapper object. Note that if this
Section 28.17.5 discusses the configuration requirements for enabling automatic endpoint registration in servers. It should be noted however that IceGrid simplifies the configuration process in two ways:
