Manage application servers

We can use either the console or command-line tools to manage the application servers.

If we plan to change the system clock, stop all the application servers, the node agent servers, the deployment manager server, the administrative agent server, and the job manager server first. After you stop the servers, change the system clock, and then restart the servers. If we change the system clock on one system, you must ensure the clocks on all systems that communicate with each other and have WAS installed are synchronized. Otherwise, you might experience errors, such as security tokens no longer being valid.

(zos) If we plan to change the system clock, stop all the application servers, the node agent servers, the deployment manager server, the administrative agent server, the job manager server, and the location service daemon first. After you stop the servers and location service daemon, change the system clock, and then restart the servers and location service daemon. If we change the system clock on one system, you must ensure the clocks on all systems that communicate with each other and have WAS installed are synchronized. Otherwise, you might experience errors, such as security tokens no longer being valid.

(iseries) If an application server is running on an operating system when the time zone setting for the operating system is updated, the application server updates its internal time stamp. Because of a delay between the change for the time zone and the change to the application server internal time stamp, an incorrect time stamp could be posted for a file if the file is touched during this delay. The delay could be several seconds. If the file is part of an application, this incorrect time stamp would cause the application to stop and then restart because the application server thinks that the application has been updated.

transition: If we are migrating from a previous version of the product, we can upgrade a portion of the nodes in a cell, while leaving others at the previous release level. This means that, for a period of time, you might be managing servers that are running at different release levels in the same cell. In this mixed environment, some restrictions exist for what we can do with servers that are running at a previous release level. No restrictions exist for what we can do with the servers that are running on the newest release level.

We can perform the following steps to view and manage an application server from the console.

1. In the console click Servers > Server Types > WebSphere application servers.

   The Application servers page lists the application servers in the environment and the status of each of these servers. We can use this page to complete the following actions:

   • Create additional servers.

   • Monitor running servers.

   • Control the status of a server.

   • Create a server template

   • Delete a server. When you select a server for deletion, click Delete and OK before the server is deleted.

     If the server you are deleting has applications or modules mapped to it and is not part of a cluster, remap the modules to another server, or create a new server and remap the modules to the new server, before we delete this server. After a server to which modules are mapped is deleted, we cannot remap these modules to another server. If we do not remap the modules to another server before we delete this server, you must uninstall all of the modules that were mapped to this server, and then reinstall them on a different server.

     If the server you are deleting is part of a cluster, any application installed on this server is automatically installed on all of the other servers in the cluster. Therefore, deleting one cluster member does not affect the other cluster members, and the application remains installed in the cluster. Similarly when a new member is added to an existing cluster, any applications that are installed on the servers in that cluster are automatically installed on the new cluster member.

2. Click the name of a listed server to view or change the configuration settings for that server.

   We can use this console page to:

   • Change the configuration settings for the selected server.

     For example, if we do not need to have all of the sever components start during the server startup process, you might want to select Start components as needed, which is not automatically selected when a new server is created. When this property is selected, server components are dynamically started as they are needed. When this property is not selected, all of the server components are started during the startup process. Therefore, selecting this property usually results in improved startup time because fewer components are started during the startup process.

   • View the status of applications running on the selected server. To view the status of applications running on this server, under Applications, click Installed Applications.

3. (zos) Click Custom properties to add new custom properties, update existing custom properties, or modify the timer settings if the current settings are causing timeout problems.

4. Click Review, select Synchronize changes with Nodes.

5. Click Save to save any configuration changes made.

6. If we made any configuration or custom property changes, start the application server, or stop and restart the application server if it is already running.

Results

When you click Servers > Server Types > WebSphere application servers, we can view the state of each server.

When you click Servers > Server Types > WebSphere application servers > server_name, we can view any configuration changes you made.

What to do next

We can deploy applications or components to the application servers.

Subtopics

• Server collection
  Use this topic to learn how to navigate within the console to the pages where we can view information about the application servers, generic servers, Java message service (JMS) servers, and web servers defined for the system.

• Application server settings
  Use this page to configure an application server or a cluster member template. An application server is a server that provides services required to run enterprise applications. A cluster member template is the set of application server configuration settings assigned to new members of a cluster.

• Core group service settings
  Use this page to set up the application server properties that relate to core groups.

• (zos) Switching between 64 and 31 bit modes
  When creating a new application server, it is automatically configured to run in 64-bit mode. We can deselect the Run in 64 bit JVM mode setting if we need to run the server in 31-bit mode. Whenever possible, however, leave the servers configured to run in 64-bit mode because support for running servers in 31-bit mode is deprecated. If we have any servers, that you migrated from a previous version of the product, that are running in 31-bit mode, consider reconfiguring them to run in 64-bit mode.

• (zos) Change the values of variables referenced in BBOM0001I messages
  BBOM0001I messages are issued during server startup, and indicate the product configuration settings. Unless otherwise indicated, these variables apply to all application servers, including the deployment managers, node agents, and JMS servers.

• Environment entries collection
  Use this page to view and manage arbitrary name-value pairs of data, where the name is a environment entry key and the value is a string value that can be used to set internal system configuration environment entries.

• (zos) Update resources for an application server
  Properly updating resources ensures that all transactional work completes while the original versions of the resources are still available. If resources are not properly updated, data builds up in the transaction partner log. Eventually high CPU usage is observed in the controller.

• Start an application server
  When you start an application server, a new server process starts. This new server process is based on the process definition settings of the current server configuration.

• Directory conventions
  References in product information to app_server_root, profile_root, and other directories imply specific default directory locations. Become familiar with the conventions in use for WebSphere Application Server.

• Restart an application server in recovery mode
  When an application server instance with active transactions in progress restarts after a failure, the transaction service uses recovery logs to complete the recovery process. These logs, which each transactional resource maintains, are used to rerun any InDoubt transactions and return the overall system to a self-consistent state.

• (iseries) Run application servers under specific user profiles
  We can run an application server under a user profile other than the default QEJBSVR user profile.

• Detecting and handling problems with runtime components
  We must monitor the status of runtime components to ensure that, once started, they remain operational as needed.

• Stopping an application server
  Stopping an application server ends a server process based on the process definition settings in the current application server configuration.

• (zos) Automatically rejecting work requests when no servant is available to process these requests
  When a controller determines that a servant has terminated, the controller normally cleans up any other work requests that were dispatched in that servant. If that servant is the last servant, new work requests are placed in the request queue until a servant is available. Depending on how long it takes for a servant to become available, these requests might terminate because the time allowed to process a request has expired. To prevent this from happening, we can change the configuration settings for an application server to prevent the controller from accepting new requests.

• (zos) Converting a 7-character server short name to 8 characters
  By default, the product assumes you are using a 7-character short name (JOBNAME) for the application servers and deployment managers. If the naming standards require 8 characters, we can lengthen the 7-character server short name to 8 characters.

• Change time zone settings
  In some application environments, it is important that application server components use the same time zone. We can use the console or system environment variables to ensure that the application components use the correct time zone.

• (iseries) Change the ports associated with an application server
  We can use the console or tools to manage the application servers.

• Web module or application server stops processing requests
  If an application server process spontaneously closes, or web modules stop responding to new requests, it is important that you quickly determine why this stoppage is occurring. We can use some of the following techniques to determine whether the problem is a web module problem or an application server environment problem.

• (zos) Set a time limit for the completion of RMI/IIOP enterprise bean requests
  The Request timeout ORB Service setting determines how long a client waits for a response from an outbound RMI/IIOP enterprise bean invocation. This setting is a server-wide setting that applies to each IIOP locate and request message that is sent as a result of an enterprise bean invocation. When the specified time limit expires, the application that invoked the outbound RMI/IIOP enterprise bean receives an org.omg.CORBA.COMM_FAILURE system exception.

• Prepare to host applications
  Rather than use the default application server provided with the product, we can configure a new server and set of resources.

• Configure an application server, a node, or a cell to use a single network interface
  Application servers, by default, are configured to use all of the network interfaces that are available for them to use. We can change this configuration such that an application server only uses a specific network interface. However, we cannot configure it to use a subgroup of interfaces. For example, if we have three ethernet adapters, we cannot configure an application server to use two of the three adapters.

• Configure application servers for UCS Transformation Format
  We can use the client.encoding.override=UTF-8 JVM argument to configure an application server for UCS Transformation Format. This format enables an application server to handle most character encodings, including specialized mathematical and technical symbols.

Related tasks

Create application servers

Get started with wsadmin scripting

Hot deployment and dynamic reloading

Restarting an application server in recovery mode

Security considerations when in a multi-node WebSphere Application Server WebSphere Application Server Network Deployment environment

Create clusters

(zos) Application server custom properties for z/OS