Server Instance Synchronization (Sun GlassFish Enterprise Server 2.1 High Availability Administration Guide)

Sun GlassFish Enterprise Server 2.1 High Availability Administration Guide

Server Instance Synchronization

If you explicitly start a server instance with the Admin Console or asadmin tool, the server instance is synchronized with the central repository. If this synchronization fails, the server instance doesn’t start.

If a node agent starts a server instance without an explicit request through the Admin Console or the asadmin tool, the repository cache for the server instance is not synchronized. The server instance runs with the configuration as stored in its cache. You must not add or remove files in the remote server instance's cache.

The remote server instance's configuration are treated as cache (all files under nodeagents/na1/server1) and owned by Application Server. In extreme cases, if user removes all files of a remote server instance and restarts the node agent, the remote server instance (for example, server1) will be recreated and all necessary files will be synchronized.

The following files and directories are kept synchronized by the Application Server.

Table 8–1 Files and directories synchronized among remote server instances


File or directory	Description
`applications`	All deployed applications. The parts of this directory (and sub directories) synchronized depend on the applications referred to from the server instance. The Node agent does not synchronize any of the applications because it does not reference any application.
`config`	Contains configuration files for the entire domain. All the files in this directory are synchronized except runtime temporary files, such as, `admch`, `admsn`, `secure.seed`, . `timestamp`, and `__timer_service_shutdown__.dat`.
`config/config_name`	Directory to store files to be shared by all instances using config named `config_name`. There will be one such directory for every config defined in domain.xml. All the files in this directory are synchronized to the server instances that are using the `config_name`.
`config/config_name/lib/ext`	Folder where Java extension classes (as zip or jar archives) can be dropped. This is used by applications deployed to server instances using config named `config_name`. These jar files are loaded using Java extension mechanism.
`docroot`	The HTTP document root. In out of the box configuration, all server instances in the domain use the same docroot. The docroot property of the virtual server needs to be configured to make the server instances use a different docroot.
`generated`	Generated files for Java EE applications and modules, for example, EJB stubs, compiled JSP classes, and security policy files. This directory is synchronized along with applications directory. Therefore, only the directories corresponding to applications referenced by a server instance are synchronized.
`lib`, `lib/classes`	Folder where common Java class files or jar and zip archives used by applications deployed to entire domain can be dropped. These classes are loaded using Application Server's class loader. The load order in class loader is: `lib/classes`, `lib/.jar`, `lib/.zip`.
`lib/ext`	Folder where Java extension classes (as zip or jar archives) used by applications deployed to entire domain can be dropped. These jar files are loaded using Java extension mechanism.
`lib/applibs`	Place dependent jars under `domains/<domain_name>lib/applibs` and specify a relative path to the jar file through the `libraries` option. For example, `asadmin deploy --libraries commons-coll.jar,X1.jar foo.ear`
`java-web-start`	The parts of this directory (and sub directories) are synchronized depending on the applications referred to from the server instance.