The Server Life Cycle

A server can cycle through a number of different states during its lifetime. It is useful to know how and when WebLogic transitions between these various states. You can explicitly move WebLogic Server to a new state, using either the Administration Console or the weblogic.Admin tool. Figure 13-6 illustrates the different states that a server goes through during its lifetime.

Figure 13-6. Life cycle of WebLogic Server

Let's take a closer look at the various states of the server's life cycle:

shutdown

A server that is not running is considered to be in the shutdown state. The only thing that you can do with such a server is to start it!

starting

A server that has been started from the command line or by a Node Manager moves into the starting mode. During this state, the server contacts the Administration Server, retrieves its configuration, starts all services, deploys all applications, and executes any startup classes.

standby

If an administration port has been configured, the server is capable of moving into the standby state after it has started. Otherwise, the server moves directly from the starting to the running state. In the standby state, all services are initialized and all applications are deployed. Except for the administration port, however, all ports are closed. Therefore, the server is effectively in hot standby and ready to go.

running

A server in the running state is fully operational and participating as a regular member of the domain.

suspending

A server moves into the suspending state during a graceful shutdown. This allows the server to complete any in-flight work to enable a clean shutdown without loss of important state information. This state is skipped during a forced shutdown.

shutting down

A server moves into this state after it receives a shutdown command. If the server is in either a running or a standby state when the command is received, it shuts down gracefully, terminating all services and executing any configured shutdown classes.

failed

During the server's life cycle, if the health monitoring service determines that a critical service is not functioning as it should be, the server is moved into the failed state. Once a server has failed, you can shut it down only. If you have enabled health monitoring, the Node Manager automatically can shut down and restart servers that have failed.

unknown

If a server cannot be contacted, it is in an unknown state.

You can view the state of all servers in a domain by selecting the Servers node in the left frame of the Administration Console. You can get a little more information about when a server entered its current state by selecting the server in the left pane, and then navigating to the Server/Monitoring tab from the right. You also can use the weblogic.Admin tool to fetch the state of a server. Here is an example:

java weblogic.Admin -adminurl t3://10.0.10.10:7001 -username system -password pssst GETSTATE

13.8.1 Graceful Shutdown

WebLogic supports two forms of shutdown. A graceful shutdown causes the server to transition through the following sequence of states: running, suspending, standby, shutting down, and shutdown. A forced shutdown simply moves the server from its current state into standby and then shutdown.

During a graceful shutdown, the server attempts to complete any in-flight work and tries to suspend the servers in an order that minimizes disruption to your applications. A graceful shutdown begins by rejecting further nontransactional remote RMI requests. After this, the web container rejects any new requests and sessions and cleans up any current sessions. The server then waits for pending client transactions to complete, after which all remote RMI requests are rejected. The timer service cancels all triggers, after which all pending work on the execute queues is completed. Any active message-driven beans then are suspended, followed by the JMS service after all pending requests are handled. Finally, all idle connections in the JDBC connection pools are closed, and the transaction service waits for all pending transactions to complete.

When the web container shuts down, it handles existing sessions (at this point, new sessions are rejected), depending on the type of persistence used for the sessions:

• If the sessions do not have persistence configured, the sessions are "allowed to complete."
• If the sessions are configured for in-memory replication, WebLogic tries to transparently move the clients across to other machines that hold the secondary session state. All the sessions that have replicated their state to a secondary server are suspended immediately. If no secondary session state is available, the container waits until a secondary session is created, or until the session times out, whichever comes first.
• If the sessions are configured for JDBC or file persistence, the sessions that are replicated are suspended immediately.

You may not want WebLogic to handle active sessions in such a graceful way because it may take some time for the sessions to complete or time out. For example, the default timeout for HTTP sessions is one hour. You can instruct WebLogic to ignore sessions during shutdown. From the Administration Console, enable the "Ignore Sessions during Shutdown" option from the shutdown panel, or use the -ignoreSessions option when invoking the weblogic.Admin tool. This forces WebLogic to drop all sessions immediately, which may result in a loss of session information.

As a compromise, it is useful to set a Graceful Shutdown Timeout period. If the timeout is set, the server waits for this duration to complete a graceful shutdown. If the period is exceeded, and the server still is not completely shut down (for example, some sessions haven't yet completed), WebLogic forces the shutdown on the server, dropping the remaining sessions. You also may want this behavior for pending transactions. Depending on the transaction timeout, completing pending transactions can take some time. The transaction service waits for all pending transactions to complete before allowing the server to shut down. To cap this time period, specify a shutdown timeout so that all pending transactional work will be suspended after the timeout expires.

13.8.2 Starting a Server

Earlier, we saw how to start a Managed Server remotely using the Administration Console (and the Node Manager). The weblogic.Admin utility also can be used to start a Managed Server remotely. Just like the Administration Console, it requires a Node Manager on the machine that hosts the target server. In fact, the tool lets you start up a server in normal or standby mode, resume a server from standby mode, or force a server to shut down. For instance, if you need to start a Managed Server in the domain remotely, you can run the tool with the START parameter:

java weblogic.Admin -url t3://10.0.10.10:7001/ -username system -password yourpassword START managedServer1

Here the Administration Server is running on port 7001, and managedServer1 is the name of a Managed Server in the domain. If you've configured a domain administration port, you must supply additional system properties in order to use the SSL-enabled administration port. The following command starts a Managed Server in a domain that uses a secure administration port:

java -Dweblogic.security.TrustKeyStore=DemoTrust weblogic.Admin -url t3s://10.0.10.10:9002/ -username system -password yourpassword START managedServer1

If you have tweaked the SSL setup, you probably will have your own trust file and want to use something like the following:

java -Dweblogic.security.TrustKeyStore=CustomTrust -Dweblogic.security.CustomTrustKeyStoreFileName=myTrust.jks -Dweblogic.security.CustomTrustKeyStorePassPhrase=passphrase weblogic.Admin -url t3s://10.0.10.10:9002/ -username system -password yourpassword START managedServer1

In WebLogic 7.0, you may run the command as follows:

java -Dweblogic.security.SSL.trustedCAKeyStore=X:cacerts -Dweblogic.security.SSL.ignoreHostnameVerification=true weblogic.Admin -url t3s://10.0.10.10:9002/ -username system -password yourpassword START managedServer1

In all these cases, the URL uses the default Administration Port 9002. Because it is a secure channel, the URL must use the T3S protocol. In addition, if you are using the demonstration certificates, you also must disable hostname verification (as we have done).

A Managed Server may be started in standby mode only if you have configured a domain-wide administration port. If a Managed Server is configured to start in standby mode, the earlier commands with the START parameter will ensure the server moves into the standby mode.

You can conveniently start, stop, and resume all of the Managed Servers in a domain at once. Choose the domain node from the Administration Console and navigate to the Control tab to use this functionality.

13.8.3 Standby Mode

In the standby state, a Managed Server is ready to become an active member of the domain. All services are initialized and all applications are deployed. No network channels are available to the client, and only the Administration Channel is active. Here are the steps to follow:

1. Ensure that the domain-wide administration port has been configured and enabled.
2. Using the Administration Console, select the server from the left pane and then set the "Startup mode" attribute in the Configuration/General tab to STANDBY. This means that whenever the Managed Server is started, it will move into the standby state.

   Alternatively, you can explicitly start the server in standby mode with an additional system property in the startManagedWeblogic script:

   -Dweblogic.management.startupMode=STANDBY

   Note that this setting will override the Startup Mode specified for the Managed Server using the Administration Console.

   If the Node Manager is set up on the machine that hosts the server, you also can start the server in standby mode remotely by issuing the following command:

   java weblogic.Admin -url t3s://10.0.10.10:9002/ -username system -password yourpassword STARTINSTANDBY managedServer1

Once you have started a server in standby mode, it will stop and wait for a signal to be activated. Only then will it move to the running state. To determine which servers are in the standby state, click the Servers node from the left pane of the Administration Console. The State column indicates STANDBY for those servers that are in this state.

You can move a server from a standby state into a running state from the Administration Console or by using the weblogic.Admin tool. To use the console, right-click the server's node and choose the "Start/Stop this server" option. Then select the "Resume this server" option from the right pane. To use the administration tool, you can issue the RESUME command:

java weblogic.Admin -url t3s://10.0.10.10:9002/ -username system -password yourpassword RESUME managedServer1

13.8.4 Shutting Down

A server can be shut down from anywhere in its life cycle. To shut down a server from the Administration Console, right-click the server's node in the left pane and choose the "Start/Stop this server" option. Then select the "Shutdown this server" option from the right pane. To use the administration tool, you can issue the SHUTDOWN command:

java weblogic.Admin -url t3s://10.0.10.10:9002/ -username system -password yourpassword SHUTDOWN mangedServer1

The preceding command shuts down the server gracefully, and can be issued only if the server is in the running or standby state.

You can supply two additional arguments in WebLogic 8.1. Use the -timeout argument to determine the maximum number of seconds that WebLogic should wait for a graceful shutdown to complete. This effectively sets a limit on the completion of pending in-flight tasks. Without this argument, WebLogic uses the timeout value set for the server from the Administration Console. By default, this timeout value is set to 0, which means that the server will wait indefinitely. Use the -ignoreExistingSessions flag to drop all HTTP sessions immediately. Without this argument, WebLogic uses the setting defined in the Administration Console, which waits for HTTP sessions to complete or time out. Here is an example:

java weblogic.Admin -url t3s://10.0.10.10:9002/ -username system -password yourpassword SHUTDOWN -ignoreExistingSessions -timeout 10 managedServer1

In some circumstances, you may need to force a server to shut down. You can do this by issuing the FORCESHUTDOWN command:

java weblogic.Admin -url t3s://10.0.10.10:9002/ -username system -password yourpassword FORCESHUTDOWN servernameToStart

Note that a forced shutdown could result in a loss of session-state information or could cause currently active transactions to roll back. If a server was started with the Node Manager and later does not respond to a forced shutdown command, the Node Manager is asked to kill the process entirely.

13.8.5 Node Manager

If a Managed Server is under the control of a Node Manager, it can be in three additional states:

FAILED_RESTARTING

This indicates that the Node Manager currently is restarting a failed server.

ACTIVATE_LATER

This indicates that the Node Manager has tried to restart the server a number of times, and has reached its limit within the current restart interval (as described in Table 13-3). The Node Manager will attempt to restart the server later, in the next restart interval.

FAILED_NOT_RESTARTABLE

This indicates that the server has failed (or was killed), but because it isn't configured to Auto Restart, the Node Manager did not restart the server.