The Application Server creates one application server instance, called server at the time of installation. You can delete the server instance and create a new instance with a different name if you prefer.
Each Application Server instance has its own J2EE configuration, J2EE resources, application deployment areas, and server configuration settings. Changes to one application server instance have no effect on other application server instances. You can have many application server instances within one administrative domain.
For many users, one application server instance meets their needs. However, depending upon your environment, you might want to create one or more additional application server instances. For example, in a development environment you can use different application server instances to test different Application Server configurations, or to compare and test different application deployments. Because you can easily add or delete an application server instance, you can use them to create temporary “sandbox” areas to experiment with while developing.
In addition, for each application server instance you can also create virtual servers. Within a single installed application server instance you can offer companies or individuals domain names, IP Addresses, and some administration capabilities. For the users, it is almost as if they have their own web server, without the hardware and basic server maintenance. These virtual servers do not span application server instances. For more information about virtual servers, see To configure the JVM general settings.
In operational deployments, for many purposes you can use virtual servers instead of multiple application server instances. However, if virtual servers do not meet your needs, you can also use multiple application server instances.
An Application Server instance is not started automatically. Once you start an instance, the instance runs until you stop it. When you stop an application server instance, it stops accepting new connections, then waits for all outstanding connections to complete. If your machine crashes or is taken offline, the server quits and any requests it was servicing may be lost.
Application server instances form the basis of an application deployment. Each instance belongs to a single domain and has its own directory structure, configuration, and deployed applications. Each server instance also includes the J2EE platform web and EJB containers. Every new server instance must contain a reference to a node agent name defining the machine on which the instance will reside.
There are three types of server instances that can be created. Each server instance can only be of one type:
In the stand-alone server instance the configuration is not shared by any other server instance or clusters.
In the shared server instance the configuration is shared with other instances or clusters.
In the clustered server instance the configuration is shared with other instances in the cluster.
A cluster is a group of server instances sharing the same set of applications, resources, and configuration information. A server instance can belong to only one cluster. Among other things, the cluster is used to facilitate load balancing, through distribution of a load across multiple machines, and high availability, through instance level failover.
Figure 1–2 shows an application server instance in detail. The application server instance is a building block in the clustering, load balancing, and session persistence features of the Application Server Enterprise Edition.
An Application Server instance is not started automatically. Once you start an instance, the instance runs until you stop it. When you stop an application server instance, it stops accepting new connections, then waits for all outstanding connections to complete. If your machine crashes or is taken offline, the server quits and any requests it was servicing may be lost.
See Also:
From the General Tab you can perform the following tasks:
Click Start Instance to start the instance.
Click Stop Instance to stop the instance.
Click View Log Files to open the server log viewer.
Click Rotate Log File to rotate the log file for the instance.
This action schedules the log file for rotation. The actual rotation takes place the next time an entry is written to the log file. The rotation happens immediately for the default server (the DAS) but is delayed for other stand-alone server.
Click JNDI Browsing to browse the JNDI tree for a running instance.
Click Recover Transactions to recover incomplete transactions.
In addition, you can select the following tabs to perform these additional tasks:
Applications Tab: deploy a selected application.
Resources Tab: manage a selected resource.
Properties Tab: configure instance specific properties.
Monitor Tab: view monitoring data for JVM, Server, Thread Pools, HTTP Service, and Transaction Service.
Advanced Tab: set general properties for deploying applications.
From the Applications Tab, you can enable, disable, and deploy selected applications associated with the instance.
Select the checkbox for the desired application.
From the Deploy drop down menu, select the type application module you want to deploy:
Enterprise Application: a J2EE application in an EAR (Enterprise Application Archive) file or directory.
Web Application: a collection of Web resources such as JavaServer Pages (JSPs), servlets, and HTML pages that are packaged in a WAR (Web Application Archive) file or directory.
EJB Module: one or more Enterprise JavaBeans (EJB components) contained in an EJB JAR (Java Archive) file or directory.
Connector Module: connects to an Enterprise Information System (EIS) and is packaged in a RAR (Resource Adapter Archive) file or directory.
Lifecycle Module: performs tasks when it is triggered by one or more events in the server’s lifecycle.
App Client Module: also called a J2EE application client JAR file, contains the server-side routines for the client.
From the Resources Tab, you can enable, disable, and create a new resource type to associate with the instance.
Select the checkbox for the desired resource.
From the New drop down menu, select the resource type you want to create and associate with that instance:
JDBC: provide applications with a means of connecting to a database.
Persistence Manager: required for applications with container-managed persistence beans (needed for backward compatibility).
JMS Connection Factory: objects that allow an application to create other JMS objects programmatically.
JMS Destination: represents a mail session in the JavaMail API, which provides a platform-independent and protocol-independent framework to build mail and messaging applications.
JavaMail: provides a platform-independent and protocol-independent framework to build mail and messaging applications.
Custom: represents nonstandard resources with a defined JNDI subcontext, resource type, and factory class.
External: enables an application to locate an external resource object in a Lightweight Directory Access Protocol (LDAP) repository.
Connector: a program object that provides an application with a connection to an enterprise information systems (EIS).
Admin Object: configures a JSR-160 compliant remote JMX connector.
The Administration Server Advanced settings allow you to set general properties for deploying applications. These properties enable you to ensure and monitor that changes to deployed applications are detected and the modified classes reloaded.
If dynamic reloading is enabled, the server periodically checks for changes in the files of the deployed application and automatically reloads the application with the changes. Dynamic reloading is useful in a development environment because it allows code changes to be tested quickly. In a production environment, however, dynamic reloading may degrade performance.
Dynamic reloading is intended for development environments. It is incompatible with session persistence, a production environment feature. Do not enable session persistence if dynamic deployment is enabled.
Dynamic reloading is only available for the default server instance.
To configure dynamic reloading from the Applications Configuration page, configure the following:
Reload: Enable or disable dynamic reloading with the Enabled checkbox.
Reload Poll Interval: Specify how often the server checks for changes in the deployed applications.
Admin Session Timeout: Specify the amount of time before the Admin Session times out and you have to log in again.
The auto deploy feature enables you to deploy a prepackaged application or module by copying it to the domain-dir/autodeploy directory.
For example, copy a file named hello.war to the domain-dir/autodeploy directory. To undeploy the application, remove the hello.war file from the autodeploy directory.
The auto deploy feature is intended for development environments. It is incompatible with session persistence, a production environment feature. Do not enable session persistence if auto deploy is enabled.
Auto deploy is only available for the default server instance.
Go to the Applications Configuration page.
Enable or disable auto deploy by selecting or deselecting the Enabled checkbox.
In the Auto Deploy Poll Interval field, specify how often the server checks the auto deploy directory for application or module files.
Changing the poll interval does not affect the amount of time it takes to deploy an application or module.
In the Auto Deploy directory, if you specify the directory where you build your application, then you won’t have to copy the file to the default auto deploy directory.
By default a variable is used to eliminate the need to manually change the directory for multiple server instances.
To run the verifier before deployment, select the Verifier Enabled checkbox.
The verifier examines the structure and content of the file. Verification of large applications is often time-consuming.
To precompile JSP pages, select the JSPs checkbox.
If you do not select this checkbox, the JSP pages are compiled at runtime when they are first accessed. Because compilation is often time-consuming, in a production environment select this checkbox.
Click the Add Property button to specify additional settings.
The following domain attributes properties are available.
Table 1–1 Domain Attributes values
Property |
Definition |
---|---|
com.sun.aas.installRoot |
Directory where the application server is installed. |
com.sun.aas.instanceRoot |
Top level directory for a server instance. |
com.sun.aas.hostName |
Name of the host (machine). |
com.sun.aas.javaRoot |
.J2SE installation directory. |
com.sun.aas.imqLib |
Library directory of the Sun Java System Message Queue software. |
com.sun.aas.configName |
Name of the configuration being used by a server instance. |
com.sun.aas.instanceName |
Name of the server instance. This property is not available for the default-config but can be used for customized configurations. |
com.sun.aas.clusterName |
Name of the cluster. This property is only set on the clustered server instances. This property is not available for the default-config but can be used for customized configurations. |
com.sun.aas.domainName |
Name of the domain. This property is not available for the default-config but can be used for customized configurations. |
The instance specific Configuration Properties override the values for this instance.
The default values are defined in the configuration bound to the instance.
Click the Add Property button to specify additional settings.
The following property attribute name/value pairs for configuring the resource are available:
Property |
Definition |
---|---|
HTTP_LISTENER_PORT |
This port is used to listen for HTTP requests. This property specifies the port number for http-listener-1. Valid values are 1-65535. On UNIX, creating sockets that listen on ports 1-1024 requires superuser privileges. |
HTTP_SSL_LISTENER_PORT |
This port is used to listen for HTTPS requests. This property specifies the port number for http-listener-2. Valid values are 1-65535. On UNIX, creating sockets that listen on ports 1-1024 requires superuser privileges. |
IIOP_LISTENER_PORT |
This property specifies which ORB listener port for IIOP connections orb-listener-1 listens on. |
IIOP_SSL_LISTENER_PORT |
This port is used for secure IIOP connections. |
JMX_SYSTEM_CONNECTOR_PORT |
This property specifies the port number on which the JMX connector listens. Valid values are 1-65535. On UNIX, creating sockets that listen on ports 1-1024 requires superuser privileges. |
IIOP_SSL_MUTUALAUTH_PORT |
This property specifies which ORB listener port for IIOP connections the IIOP listener called SSL_MUTUALAUTH listens on. |
In the tree component, select the Standalone Instances node.
On the Stand Alone Server Instances page, click New.
In the Name field, identify a unique name for the new instance.
Select a Node Agent.
The node agent must be started using the asadmin start-node-agent command on the node agent’s host machine so that the server instance you are creating can be associated with that node agent.
Select a desired configuration.
To copy from a different configuration, specify it when creating the new instance.
By default, new instances are created with configurations copied from the default-config configuration.
For a server instance, the new configuration is named instance-name-config.
The configuration default-config is the default configuration that acts as a template for creating standalone server instance. No unclustered server instances or clusters are allowed to refer to the default-config configuration; it can only be copied to create new configurations. Edit the default configuration to ensure that new configurations copied from it have the correct initial settings.
create-instance
In the tree component, expand the Stand-Alone Instances node.
Select the Instance you wish to start.
On the General tab, click Start Instance to start the instance.
The node agent associated with the instance must be started using the asadmin start-node-agent command before you can successfully start the instance.
Once an instance is started, it is possible to perform the following tasks from the General tab:
start-instance
Transactions might be incomplete either because the server crashed or a resource manager crashed. It is essential to complete these stranded transactions and recover from the failures. Application Server is designed to recover from these failures and complete the transactions upon server startup.
If the selected server is running, then recovery will be done by the same server. If the selected server is not running, then the selected Destination Server will do the recovery.
In the tree component, expand the Standalone Instances node.
Select the Instance you wish to stop.
On the General tab, click Stop Instance to stop the instance.
stop-instance