WebLogic Server 8.1 Life Cycle

Server Life Cycles

Overview

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.
You can determine the current state of a server using any of the following methods:

console --> Servers --> Monitoring
java weblogic.Admin ... GETSTATE
Server log files

Server States

SHUTDOWN

Server instance is configured, but inactive.
Graceful shutdowns can be initiated when the server instance is in the RUNNING or the STANDBY state and consists of the following state transitions:
RUNNING --> SUSPENDING --> STANDBY --> SHUTTING DOWN --> 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

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.
A server instance can enter the STARTING state only from the SHUTDOWN state as a result of a start command.
SHUTDOWN --> STARTING --> RUNNING

STANDBY

A server has initialized all of its services and applications, can accept administration commands, and can participate in a cluster. However, it does not accept requests from external clients.
A server instance enters the standby state when:

It is started in standby mode with start command or from the console at:
Server --> Configuration --> General

Starting a server instance in standby mode requires a domain-wide administrative port.
Starting a server instance in standby is a method of keeping it available as a "hot" backup since it 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

Running server instances offer services to multiple clients and operate as full members of a cluster. A server instance can enter a 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, in which case it 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

During the forced shutdown process, a server instance goes through the following state transitions:
any state --> STANDBY --> 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.
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.
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 console, and provide visibility into the status of the restart process.

Life Cycle Commands

Start

When a server instance starts, it:

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.
Starts its kernel-level services:

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

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.
Deploys modules in the appropriate container and in the order that you specify in the WebLogic Server 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 Webapps and EJBs.
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. Work completed during the shutdown is referred to as in-flight work, and is done in the following order:

Non-Transaction RMI Service
Web Container
Client Initiated Transaction Service
Remote RMI Service
Timer Service
Application Service
EJB Container
JMS Provider
JDBC Container
Transaction Service

To configure the length of the shutdown process, go to:
Server --> Control --> Start/Stop tab:

One can tweak the following:

Ignore Sessions During Shutdown
Enable this option to drop all HTTP sessions immediately, rather than waiting for them to complete or timeout. The default session timeout is one hour. If you are unable to shutdown a server in a reasonable length of time, and your log files indicate that sessions cannot be closed due to excessive timeout values of active sessions, this is the value to set.
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.

See also the -ignoreExistingSessions option to the java weblogic.Admin ... SHUTDOWN command.

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

Non-transaction remote requests are rejected by the Non-Transaction RMI Service.
The Client Initiated Transaction Service waits for pending client transactions to complete.
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, from the console:
Servers --> Control --> Start/Stop --> Ignore Sessions During Shutdown

Or use the -ignoreExistingSessions 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 and waits for its reference count of pending requests to drop to zero.

JDBC Service

The JDBC Service closes idle connections in the connection pools.

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 during calls to a servlet destroy method or ejbRemove. Normally these calls are used to release application resources. During the shutdown sequence resources managed by the server instance, such as JDBC connection pools and JMS sessions, are closed by the server instance in a particular sequence. If application code called as a result of the undeployment step tries to release a resource that the server instance already released, the application code should be written to handle an exception.
For example:
import weblogic.management.runtime.ServerStates;
try 
{
    // user code that gets called during shutdown sequence.
    // tries to close a JMS session that is already closed
    // by the server as a part of the shutdown sequence.
} 
catch (JMSException e) 
{
    // lookup the local ServerRuntimeMBean. We already have
    // an example for this.
    String state = serverRuntime.getState();

    // during forced or graceful shutdown the server closes 
    // the session for us already. During redeploy we need to 
    // do it ourselves.
    if (!state.equals(ServerStates.SUSPENDING) 
     && !state.equals(ServerStates.SHUTTING_DOWN) 
     && !state.equals(ServerStates.STANDBY)) 
    {
            // handle the exception since it is not generated
            // during shutdown sequence. 
    }
}
Resources maintained by the server instance are released by the server in a particular order during the shutdown sequence. User code that gets called during the shutdown undeployment step should release only resources that the server is unaware of.resources that the application created, and which do not involve the server instance, for instance a plain socket connection.

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.

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.