Skip navigation.
Downloads | Product Documentation | Support

Configuring and Managing WebLogic Server

# Server Life Cycle

At any time, a WebLogic Server instance is in a particular operating state. Commands—such as start, stop, and suspend—cause specific changes to the state of a server instance. The following sections describe WebLogic Server states, state transitions, life cycle commands.

- Life Cycle Overview
- Understanding WebLogic Server States
- Life Cycle Commands

# Life Cycle Overview

The series of states through which a WebLogic Server instance can transition is called the server life cycle. Figure 7-1 illustrates the server life cycle and the relationships between WebLogic Server operating states.

Figure 7-1 The Server Life Cycle

To understand each state, and the relationships among states, see Understanding WebLogic Server States.

# Understanding WebLogic Server States

WebLogic Server displays and stores information about the current state of a server instance, and state transitions that have occurred since the server instance started up. This information is useful to administrators who:

- Monitor the availability of server instances and the applications they host.
- Perform day-to-day operations tasks, including startup and shutdown procedures.
- Diagnose problems with application services.
- Plan correction actions, such as migration of services, when a server instance fails or crashes.

## Getting Server State

There are multiple methods of accessing the state of a server instance:

- Administration Console—Multiple pages display state information:

- The Servers table on the Servers page displays the current state of each server instance in the current domain.
- The Server—>Monitoring tab displays the state of the current server instance, and the date and time it entered the state.
- The log file for a server, available from the Server Log command on all Server tabs, includes timestamped messages for state transitions that have occurred since the server instance was last started.

- Programmatically—You can obtain the state of a server instance programmatically, using the `getState()` method on the server's `weblogic.management.runtime.
  ServerRuntimeMBean`. For example, to monitor the progress of a long-running graceful shut down process, issue a `getstate` inquiry on a separate thread. For more information see Accessing Runtime Information in Programming WebLogic Management Services with JMX.
- Command Line Interface—For information about obtaining state information from a command line interface, see GETSTATE in WebLogic Server Command-Line Interface Reference.

## Understanding Server State

The following sections describe the key states that a server instance can have, the processing associated with the state, and how the state fits into a sequence of state transitions.

### SHUTDOWN

In the `SHUTDOWN` state, a server instance is configured but inactive. A server instance reaches the `SHUTDOWN` state as a result of a graceful shutdown or forced shutdown.

A graceful shutdown can be initiated when the server instance is in the `RUNNING` or the `STANDBY` state. The graceful shutdown process consists of the following state transitions:

`RUNNING`—>`SUSPENDING`—>`STANDBY`—>`SHUTTING DOWN`—>`SHUTDOWN`

See Graceful Shutdown.

A forced shutdown can be initiated from any server state. The forced shutdown process consists of the following state transitions:

`any state`—>`STANDBY`—>`SHUTTING DOWN`—>`SHUTDOWN`

See Forced Shutdown.

See Starting and Stopping Servers in Administration Console Online Help.

### STARTING

In the `STARTING` state, a server instance prepares itself to accept requests and perform application processing. A server instance cannot accept requests while in the `STARTING` state.

When a server instance starts itself, it retrieves its configuration data, starts its kernel-level services, initializes subsystem-level services, deploys applications, and loads and runs startup classes. For more information about the startup process, see Start.

A server instance can enter the `STARTING` state only from the `SHUTDOWN` state as a result of a Start command.

`SHUTDOWN`—>`STARTING`—>`RUNNING`

See Starting and Stopping Servers in Administration Console Online Help.

### STANDBY

In the `STANDBY` state, a server has initialized all of its services and internal applications (such as the Administration Console), can accept administration commands, and can participate in cluster communication. Non-internal applications are partially deployed; when you move the server to the `RUNNING` state it completes the remainder of the deployment process. A server in the `STANDBY` state does not accept requests from external clients.

A server instance enters `STANDBY` when:

- It is started in standby mode with Start command. You can start a server instance in either Running or Standby mode. Configure Start Mode for a server instance on the advanced options portion of its Server—>Configuration—>General tab. The default Start Mode is Running. Starting a server instance in standby mode requires a domain-wide administrative port. For more information, see the following:

- Administration Port Requires SSL.
- "Starting a Managed Server in the STANDBY State" in the Administration Console Help.

Starting a server instance in standby is a method of keeping it available as a "hot" backup, especially in a high-availability environment. A server instance started in standby can be quickly brought to the running state to replace a failed server instance.

A server instance started in standby mode goes through the following state transitions:

`SHUTDOWN`—>`STARTING`—>`STANDBY`

- Shut down, either gracefully or forcefully. A server instance transitions through the `STANDBY` state during any shutdown process.

During the graceful shutdown process, a server instance goes through the following state transitions:

`RUNNING`—>`SUSPENDING`—>`STANDBY`—>`SHUTTING DOWN`—>`SHUTDOWN`

During the forceful shutdown process, a server instance goes through the following state transitions:

`any state`—>`STANDBY`—>`SHUTDOWN`

### RESUMING

A server instance enters the `RESUMING` state as a result of the Resume command. A server instance that is resumed from the `STANDBY` goes through the following state transitions:

`STANDBY`—>`RESUMING`—>`RUNNING`

### RUNNING

When a server instance is in the `RUNNING` state, it offers its services to clients and can operate as a full member of a cluster. A server instance can enter the `RUNNING` state if:

- It is started using the Start command. During the regular startup process, a server instance goes through the following state transitions:

`SHUTDOWN`—>`STARTING`—>`RUNNING`

- It is started with the Resume command. During the resume process, a server instance goes through the following state transitions:

`STANDBY`—>`RESUMING`—>`RUNNING`

### SUSPENDING

A server instance enters this state during the graceful shutdown process. While in the `SUSPENDING` state, the server handles a predefined portion of the work that is currently in process—referred to as "in-flight" work. The processing a server instance perform for in-flight work while in the `SUSPENDING` state is described in In-Flight Work Processing. Upon completion of in-flight work, the server progresses from the `SUSPENDING` state to the `SHUTTING_DOWN` state.

During the graceful shutdown process, a server instance goes through the following state transitions:

`RUNNING`—>`SUSPENDING`—>`STANDBY`—>`SHUTTING DOWN`—>`SHUTDOWN`

### SHUTDOWN

A server instance enters the shutdown state as a result of a graceful shutdown or forced shutdown process.

During the graceful shutdown process, a server instance goes through the following state transitions:

`RUNNING`—>`SUSPENDING`—>`STANDBY`—>`SHUTTING DOWN`—>`SHUTDOWN`

See Graceful Shutdown.

During the forced shutdown process, a server instance goes through the following state transitions:

`any state`—>`STANDBY`—>`SHUTDOWN`

See Forced Shutdown.

### FAILED

A server instance enters the `FAILED` state when one or more critical services become dysfunctional. When a server instance finds one or more critical subsystems have failed, the server instance sets its state to `FAILED` to indicate that the it cannot reliably host an application.

To recover from the `FAILED` state, a server instance must be shutdown and restarted, either manually, or automatically with Node Manager, if it is configured on the host machine. For information about automatic restarts, see Shut Down Failed Managed Servers.

A server instance can only enter the `FAILED` state from the `RUNNING` state:

`RUNNING`—>`FAILED`

### UNKNOWN

If a server instance cannot be contacted, it is in the `UNKNOWN` state.

### States Defined by Node Manager

When Node Manager restarts a failed or killed Managed Server, it defines additional server states, which are described in Node Manager and Managed Server States. These states are displayed in the Administration Console, and provide visibility into the status of the restart process.

For information about Node Manager, see Overview of Node Manager.

# Life Cycle Commands

This section describes key commands that affect the state of a server instance, and the processing a server instance performs as a result of the command. For information about issuing life cycle commands, see Starting and Stopping Servers in Administration Console Online Help.

For information about Node Manager processing related to key lifecycle events in environments that use Node Manager, see Node Manager Communications for Lifecycle Operations.

## Start

When a server instance starts, it:

1. Retrieves its configuration data.

An Administration Server retrieves domain configuration data, including security configuration data, from the `config.xml` for the domain.

A Managed Server contacts the Administration Server for its configuration and security data. If you set up SSL, a Managed Server uses its own set of certificate files, key files, and other SSL-related files and contacts the Administration Server for the remaining configuration and security data.

2. Starts its kernel-level services, which include logging and timer services.

Initializes subsystem-level services with the configuration data that it retrieved in step 1. These services include the following:

Security Service RMI Service Cluster Service IIOP Service Naming Service RMI Naming Service File Service | JCA Container JDBC Container EJB Container Web Container Deployment Manager JMS Provider Remote Management Transaction Service

3. If the server instance is in a domain for which a domain-wide administration port is configured, the server instance enables remote configuration and monitoring. For information about administration ports, see Administration Port Requires SSL.
4. Deploys modules in the appropriate container and in the order that you specify in the WebLogic Server Administration Console.

Startup classes that are configured to load before application deployments are loaded and run after the server instance deploys JDBC connection pools and before it deploys Web applications and EJBs.

5. Startup classes that are configured to load after application deployments are loaded and run.

## Graceful Shutdown

A graceful shutdown gives WebLogic Server subsystems time to complete certain application processing currently in progress. The work that it completes during graceful shutdown is referred to as in-flight work. During a graceful shutdown, subsystems complete in-flight work and suspend themselves in a specific sequence and in a synchronized fashion, so that back-end subsystems like JDBC connection pools are available when front-end subsystems are suspending themselves.

Note: The graceful shutdown process synchronizes shutdown operations and in-flight work for WebLogic execute queue threads. Applications that create threads must control the in-flight processing for pending work in application threads; this can be accomplished in a shutdown class.

### Graceful Shutdown Sequence

The following list shows the order in which subsystems suspend themselves. Each subsystem completes its in-flight work before the next one commences its preparation to suspend.

1. Non-Transaction RMI Service
2. Web Container
3. Client Initiated Transaction Service
4. Remote RMI Service
5. Timer Service
6. Application Service
7. EJB Container
8. JMS Provider
9. JDBC Container
10. Transaction Service

### Controlling Graceful Shutdown

`ServerMBean` has two new attributes for controlling the length of the graceful shutdown process. Their values are displayed and configurable on the Server—>Control—>Start/Stop tab:

- Ignore Sessions During Shutdown— If you enable this option WebLogic Server will drop all HTTP sessions immediately, rather than waiting for them to complete or timeout. Waiting for abandoned sessions to timeout can significantly lengthen the graceful shutdown process, because the default session timeout is one hour.
- Graceful Shutdown Timeout—Specifies a time limit for a server instance to complete a graceful shutdown. If you supply a timeout value, and the server instance does not complete a graceful shutdown within that period, WebLogic Server performs a forced shutdown on the server instance.

### In-Flight Work Processing

The following sections describe how each subsystem handles work in process when it suspends itself during a graceful shutdown.

#### RMI Subsystem

The Remote Method Invocation (RMI) subsystem suspends in three steps. Each step in this process completes before the following step commences.

1. Non-transaction remote requests are rejected by the Non-Transaction RMI Service.
2. The Client Initiated Transaction Service waits for pending client transactions to complete.
3. The Remote RMI Service rejects all remote requests with or without transactions.

After these steps are completed, no remote client requests are allowed. Requests with administrative privileges and internal system calls are accepted.

When a clustered server instance is instructed to prepare to suspend, the RMI system refuses any in-memory replication calls, to allow other cluster members to choose new hosts for replicated sessions.

#### Web Container

After the Web Container subsystem is instructed to prepare to suspend, it rejects new sessions requests. Existing sessions are handled according to the persistence method:

- No persistence—Pending sessions with no persistence are allowed to complete.
- In-memory replication in a cluster—Sessions with secondary sessions are immediately suspended. If a primary session does not have a secondary session, the Web Contains waits until a secondary session is created, or until the session times out, whichever occurs first.
- JDBC persistence and file persistence—The Web Container immediately suspends sessions that are replicated in a database or file store.

The completion of pending sessions is optional. To drop all sessions immediately, use the Ignore Sessions During Shutdown option on the Servers—>Control—> Start/Stop tab in the Administration Console, or the `-ignoreSessions` option with `weblogic.Admin`.

#### Timer Service

The Timer Service cancels all triggers running on application execute queues. Application execute queues include the default queue and queues configured through the `ExecuteQueueMBean`.

#### Application Service

The Application Service completes pending work in the application queues before suspending. Application execute queues include the default queue and queues configured through the `ExecuteQueueMBean`.

#### EJB Container

The EJB Container suspends Message Drive Beans (MDBs.)

#### JMS Service

The Java Messaging Service (JMS) marks itself as suspending, which causes new requests to be rejected. The JMS system suspends gracefully in this fashion:

If the server instance being shutdown has a JMS server:

- Any send requests that are waiting because of message quotas are returned immediately.
- All consumers on destinations belonging the JMS Server are closed.
- The paging store is closed.

If the server instance being shutdown has a JMS connection factory:

- Client connections are closed.

Generally each step in the graceful suspend of the JMS subsystem occurs quickly—in less than a second. Potentially, completion of a client request could take longer, if the request requires higher than normal disk I/O, for example, a request for a persistent "send" of a 100-megabyte message.

You can monitor the number of connections to a JMS server, the number of consumers to a JMS connection factory, and related run-time information using JMS run-time Mbeans, including JMSRuntimeMbean, JMSConnectionRuntimeMBean, JMSConsumerRuntimeMBean.

#### JDBC Service

The JDBC Service closes idle connections in the connection pools.

Note: If connections are still in use, the shutdown of the JDBC service will fail, and the graceful shutdown will not complete. To shut down a server instance while applications still hold connections, use a forced shutdown command, described in Forced Shutdown.

#### Transaction Service

The Transaction Service waits for the pending transaction count in the Transaction Manager to drop to zero before suspending. Completing all pending transactions can be a lengthy process, depending on the configured transaction timeout.

If a graceful shutdown takes too long because of pending transactions, you can halt it with a forced shutdown command. A forced shutdown suspends all pending work in all subsystems.

### Shutdown Operations and Application Undeployment

During both graceful and forced shutdown, subsystems undeploy applications as appropriate. This processing can result in invocation of application code, such as servlet `destroy()` or `ejbRemove()` during shutdown. During the shutdown sequence, JMS, JDBC, and transactions are shutdown after applications are shutdown, allowing application code to access JMS, JDBC, and transaction services.

## Forced Shutdown

A forced shutdown is immediate—WebLogic Server subsystems suspend all application processing currently in progress. A forced shutdown can be performed on a server instance in any state.

If a fatal exception causes the forced shutdown to fail, the server will exit after the number of seconds specified by the `ServerLifecycleTimeoutVal` attribute in `ServerMBean`.

For information about undeployment processes during a forced shutdown, and related programming considerations, see Shutdown Operations and Application Undeployment.