Application Server Instances

• About Application Server Instances

• Application Server Advanced Settings

• Instance Specific Configuration Properties

• Recovering Transactions

About Application Server Instances

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.

Viewing General Server Information

From the General Tab you can perform the following tasks:

• 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:

• JVM Settings Tab: configure the JVM general settings used by the Application Server.

• Properties Tab: configure instance specific properties.

• Logging Tab: configure the logging levels used by the Application Server.

• Monitor Tab: view monitoring data for JVM, Server, Thread Pools, HTTP Service, and Transaction Service.

• Advanced Tab: set general properties for deploying applications.

Application Server Advanced Settings

The Application 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.

Setting Applications Configurations

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.

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.

To configure auto deploy settings

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.

1. Go to the Applications Configuration page.

2. Enable or disable auto deploy by selecting or deselecting the Enabled checkbox.

3. 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.

4. 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.

   The default is a directory called domain-dir/autodeploy.

5. 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.

6. 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.

7. Click the Add Property button to specify additional settings.

Setting Domain Attributes

The following domain attributes properties are available.

Instance Specific Configuration Properties

The instance specific Configuration Properties override the values for this instance.

The default values are defined in the configuration bound to the instance.

To revert the value back to the default value

1. Remove the override value.

2. Click Save.

   If no override value is set, the default value is used.

To add instance properties

1. 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.

To delete properties

1. Click the for the property you wish to delete.

2. Click the Delete Property button.

Recovering Transactions

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.