WebLogic Administration Key Concepts

In the previous section, we discussed the core components of the WebLogic Server architecture. Now, we are ready to talk in more detail about some administrative concepts before jumping into the details of WebLogic Server administration. We begin the discussion by talking about the server life cycle. From there, we proceed to talk in more detail about server self-health monitoring, and we finish up with a discussion of network channels.

Server States

WebLogic Server formally defines the server life cycle. In previous versions of WebLogic Server, the server was basically either running or not. This caused two problems for WebLogic Server administrators. First, starting the server involved one long-running step. Depending on the number of applications in use and the required preparation work the server would perform to prepare the applications and services for use, the server could take a very long time to start up to a point where it could start accepting client requests. Second, there was no way to guarantee that the server would process all in-flight requests before shutting down. Other, less obvious problems also existed because the server did not rigorously define the boot order of its subsystems.

Figure 11.5 shows the full server life cycle state transition diagram. The four primary states are shutdown , standby , running , and failed . A server is in the shutdown state when the JVM process for that server does not exist. When a server first starts up, it initializes itself to a point where it deploys the applications and listens on the administration port, but not on its external listen ports. In standby mode, the server tries to keep its claim on shared resources to a minimum. This allows the server to act as a hot standby in conjunction with a high availability (HA) framework.

Figure 11.5:  Server life cycle state transition diagram.

In order for a server to exist in standby mode (rather than just passing through this state on the way to the shutdown or running states), you must enable the domain-wide administration port. The reason for this is simple: if the standby state does not claim the listen port resources, the only way to tell the server to change from the standby state is if it is listening for administrative commands on its administration port.

When gracefully shutting down a server, the server passes through standby mode but continues to shut down. There is currently no way to go from running to standby without stopping and restarting the server. When a server is told to shut down gracefully, the server will stop accepting new requests and will continue processing in-flight requests until all requests in its execute queues are complete. Once the server has reached a quiescent state, it will transition itself into the standby mode briefly before continuing to shut itself down. Forcing a server to shut down will not allow any in-flight requests to complete and will cause any in-flight requests to fail.

Once an initializing server reaches the standby state on its way to starting up, it is possible for the server subsystems to fail. If enough of the critical subsystems fail, the server will transition itself into the failed state. At this point, the server process is running, but it is not capable of doing any useful work. Fortunately, the node manager is now capable of monitoring the health of the server and can restart servers whose state is failed. For more detailed information on each of the states, please see the WebLogic Server documentation at http://edocs.bea.com/wls/docs81/adminguide/overview_lifecycle.html .

Server Self-Health Monitoring

WebLogic Server subsystems are responsible for monitoring their own status. The criteria each subsystem uses to determine its health status is specific to the particular subsystem. For example, the core server subsystem monitors the health of the default and user -defined execute queue thread pools. At startup, each subsystem registers itself with the server and specifies whether it is critical to the overall server s operation. Currently, the list of critical subsystems is not configurable and includes systems like RMI, JTA, and core.

The server monitors the health state of each registered subsystem and uses this information to determine the overall health of the server. Currently, the server periodically polls each subsystem to ask for its current health state. The frequency with which the server polls is controlled by the Health Check Interval parameter on the server s Health Monitoring Configuration tab. Although the WebLogic Console does not currently display the health of the server s subsystems, it is available programmatically through the JMX MBean APIs. If any of the server s critical subsystems fail, the server changes its state to failed.

Network Channels

Older versions of WebLogic Server did not support many network configuration options. Server instances could listen on one plain-text port and one SSL port. The IP address or DNS name had to be the same across both ports. As a result, the network configuration options available were limited by what the operating system provided naturally for a single TCP port environment. For example, by not specifying a listen address, the server could receive requests sent to the specified port on that machine, regardless of the IP address used to get there. This worked well for supporting machines with a single network interface card (NIC) and one or more IP addresses. Unfortunately, this method broke down if you tried to use machines with multiple NICs operating on different networks. The server was still able to receive the requests, but it could not always determine the correct IP address to embed in the response data to facilitate the next request reaching the right destination. More recent versions of WebLogic Server support defining additional listen ports (and an associated listen thread) through something called a network channel . WebLogic Server 8.1 allows you to define as many network channels as you want. Use the server s Channels Protocols tab in the WebLogic Console to manage a server s network channels.

A network channel is a conceptual combination of a Listen Address , Listen Port , and Protocol that must be unique within a server. Network channels can share the same address and port number provided that their protocols are different. When this happens, WebLogic Server combines these channels and creates a single listen thread and port that accepts all of the protocols with that address and port number combination. The choice of protocols includes t3, IIOP, COM, HTTP, t3s, IIOPS, HTTPS, or admin. The admin protocol is simply a network channel that accepts only administrative requests and requires the use of SSL.

Network channels also support network address translation (NAT) firewalls directly by providing the ability to specify the External Listen Address and External Listen Port attributes that WebLogic Server should use when communicating with clients through this channel. In addition, each network channel has its own TCP- related configuration parameters that you will find under the Advanced Options areas of the channel s Configuration tab in the WebLogic Console.

By providing the ability to define new network channels, WebLogic Server goes a long way toward helping you support the more complex networking requirements often found in production environments. Using network channels is completely optional, however. By default, the server still supports the old model of a single plain-text listen port, a single SSL listen port, and an optional domain-wide administration port. This default model is sometimes called the default channel; the domain-wide administration port is known as the administrative channel . WebLogic Server does not currently allow the default channel to be completely disabled. The good news, though, is that it is now possible to disable the plain-text listen port on this default channel if the SSL listen port is enabled. If you enable the domain-wide administration port, you must use it or another admin channel instead of the default channel ports for all administrative tasks ; however, its use is completely optional.

We have barely scratched the surface of network administration using network channels. Further reading is available on the BEA Web site at http://edocs.bea.com/wls/docs81/adminguide/network.html . In the next section, we will show an example of using network channels in a WebLogic Server cluster configuration.

In the next three sections, we will show the highlights of how to configure, administer, and monitor a WebLogic Server domain and discuss some of the important things to consider. This coverage is intended to provide insights into best practices in WebLogic Server domain configuration, administration, and monitoring, rather than a comprehensive, step-by-step coverage of all of the possible options. For more comprehensive coverage of WebLogic Server administration, please refer to one of the WebLogic Server Administration books available or the WebLogic Server documentation at http://edocs.bea.com/wls/docs81/admin.html .