BEA WebLogic Server ™ Configuring and Managing WebLogic Server Release 8.1 Document Revised: December 5.
Copyright Copyright © 2002 BEA Systems, Inc. All Rights Reserved. Restricted Rights Legend This software and documentation is subject to and made available only pursuant to the terms of the BEA Systems License Agreement and may be used or copied only in accordance with the terms of that agreement. It is against the law to copy the software except as specifically allowed in the agreement.
All other trademarks are the property of their respective companies. Configuring and Managing WebLogic Server -iii Part Number Document Revised Software Version N/A December 5, 2002 BEA WebLogic Server Version 8.
Contents About This Document Audience............................................................................................................ xiii e-docs Web Site................................................................................................. xiii How to Print the Document............................................................................... xiii Related Information........................................................................................... xiv Contact Us! ......
Editing config.xml.................................................................................... 1-13 Resources You Can Manage in a WebLogic Server Domain.......................... 1-13 Servers ...................................................................................................... 1-14 Clusters ..................................................................................................... 1-14 Machines................................................................................
Resources and Services ....................................................................... 2-5 Common Domain Types ............................................................................ 2-6 Domain Restrictions .......................................................................................... 2-7 Domain Directory and config.xml ............................................................. 2-7 Domain Directories Structure .............................................................
Starting and Stopping Node Manager ............................................................... 4-6 Starting Node Manager as a Service .......................................................... 4-7 Starting Node Manager with Commands or Scripts................................... 4-7 Command Syntax for Starting Node Manager.................................... 4-7 Node Manager Environment Variables ...................................................... 4-9 Node Manager Properties ..........................
UNKNOWN........................................................................................ 6-7 States Defined by Node Manager ....................................................... 6-8 Lifecycle Commands......................................................................................... 6-8 Start ............................................................................................................ 6-8 Graceful Shutdown.........................................................................
8. Protecting System Administration Operations Operations Available to Each Role ................................................................... 8-2 Default Group Associations ....................................................................... 8-3 Protected User Interfaces................................................................................... 8-4 Overlapping Permissions for System Administration MBeans and Policies on Resources.............................................................
Backing up config.xml ............................................................................. 10-6 WebLogic Server Archives Previous Versions of config.xml .......... 10-6 WebLogic Server Archives config.xml during Server Startup ......... 10-7 Backing Up Security Data........................................................................ 10-8 Backing Up the WebLogic LDAP Repository.................................. 10-8 Backing Up SerializedSystemIni.dat and Security Certificates........
Configuring Network Channels with a Cluster ...................................... 11-11 Create the Cluster ............................................................................ 11-11 Create and Assign the Network Channel ........................................ 11-11 A. Starting and Stopping Servers: Quick Reference Starting Instances of WebLogic Server ............................................................ A-2 Shutting Down Instances of WebLogic Server .......................................
CHAPTER About This Document This document describes how to configure and manage a WebLogic Server domain. The document is organized as follows: ! Chapter 1, “Overview of WebLogic System Administration.” provides an overview of WebLogic Server system administration tools and capabilities. ! Chapter 2, “Overview of WebLogic Server Domains.” provides general information about WebLogic Server domains. ! Chapter 3, “Overview of Node Manager.
! Chapter 11, “Configuring Network Resources.” describes how to optimize your WebLogic Server domain for your network. ! Chapter A, “Starting and Stopping Servers: Quick Reference.” provides quick procedures for starting WebLogic Server instances. Audience This document is written for system administrators responsible for implementing a WebLogic Server installation. e-docs Web Site BEA product documentation is available on the BEA corporate Web site.
Related Information WebLogic Server Administration Console Help at http://e-docs.bea.com/wls/docs81b/ConsoleHelp/index.html Using WebLogic Server Clusters at http://e-docs.bea.com/wls/docs81b/cluster/index.html WebLogic Server Command Reference at http://e-docs.bea.com/wls/docs81b/admin_ref/index.html Contact Us! Your feedback on BEA documentation is important to us. Send us e-mail at docsupport@bea.com if you have questions or comments.
Documentation Conventions The following documentation conventions are used throughout this document. Convention Usage Ctrl+Tab Keys you press simultaneously. italics Emphasis and book titles. monospace text Code samples, commands and their options, Java classes, data types, directories, and file names and their extensions. Monospace text also indicates text that the user is told to enter from the keyboard. Examples: import java.util.Enumeration; chmod u+w * config/examples/applications .java config.
Convention Usage | Separates mutually exclusive choices in a syntax line. Example: java weblogic.deploy [list|deploy|undeploy|update] password {application} {source} ... . . . Indicates one of the following in a command line: ! An argument can be repeated several times in the command line. ! The statement omits additional optional arguments. ! You can enter additional parameters, values, or other information Indicates the omission of items from a code example or from a syntax line.
-xvii Configuring and Managing WebLogic Server
CHAPTER 1 Overview of WebLogic System Administration The following sections provide an overview of system administration for WebLogic Server: ! “Introduction to System Administration” on page 1-2 ! “WebLogic Server Domains” on page 1-2 ! “System Administration Infrastructure” on page 1-5 ! “The Administration Server and Managed Servers” on page 1-6 ! “System Administration Tools” on page 1-8 ! “Resources You Can Manage in a WebLogic Server Domain” on page 1-13 ! “Starting and Using the Admini
1 Overview of WebLogic System Administration Introduction to System Administration WebLogic Server system administration tools allow you to install, configure, monitor, and manage one or more WebLogic Server installations. You also use the tools to manage and monitor the applications hosted on WebLogic Server. A WebLogic Server installation can consist of a single WebLogic Server instance or multiple instances, each hosted on one or more physical machines.
WebLogic Server Domains Note: All WebLogic Server instances in a domain must run the same version of the WebLogic Server software. The Administration Server must also have the same or later service pack installed as the Managed Servers in its domain. For example, the Administration Server could be running version 8.1, Service Pack 1 while the Managed Servers are running version 8.1 without Service Pack 1. For more information about domains, see Configuring Domains.
1 Overview of WebLogic System Administration Figure 1-1 depicts a possible configuration of a WebLogic Server Domain—one of many possible configurations. In the depicted domain, there are three physical machines. Machine A is dedicated as the Administration Server and hosts one instance of WebLogic Server. The System Administration Tools communicate with the Administration Server to perform configuration and monitoring of the servers and applications in the domain.
System Administration Infrastructure System Administration Infrastructure System administration infrastructure in WebLogic Server is implemented using the Java Management Extension (JMX) specification from Sun Microsystems. The JMX API models system administration functions with Java objects called MBeans. Knowledge of this implementation as described in this discussion of system administration infrastructure is not necessary to manage a WebLogic Server domain.
1 Overview of WebLogic System Administration Runtime Mbeans contain sets of attributes consisting of runtime information for active WebLogic Servers instances and applications. By retrieving the values of attributes in these runtime MBeans, you can monitor the running status of a WebLogic Server domain. Mbeans may also contain operations used to execute management functions.
The Administration Server and Managed Servers you can replace a failed Administration Server with a backup WebLogic Server instance that can assume the role of Administration Server. For more information, see Starting Administration Servers and Recovering Failed Servers. Failover for Managed Servers When a Managed Server starts, it contacts the Administration Server to retrieve its configuration information.
1 Overview of WebLogic System Administration Service Packs and WebLogic Server Instances All WebLogic Server instances in a domain must run the same version of the WebLogic Server software. The Administration Server must also have the same or later service pack installed as the Managed Servers in its domain. For example, the Administration Server could be running version 8.1, Service Pack 1 while the Managed Servers are running version 8.1 without Service Pack 1.
System Administration Tools Administration Console allows you to manage a WebLogic Server domain containing multiple WebLogic Server instances, clusters, and applications.
1 Overview of WebLogic System Administration graphical user interface. You can use only the command-line interface to manage your domain, or you may use the command-line interface in combination with other system administration tools such as the Administration Console to manage you domain. The command line interface invokes a Java class called weblogic.Admin. Arguments for this class provide the ability to perform many common management functions without the need to learn the JMX API.
System Administration Tools For more information, see: ! Programming WebLogic JMX Services at http://e-docs.bea.com/wls/docs81b/jmx/index.html. ! WebLogic Server API Reference (Javadocs) at http://e-docs.bea.com/wls/docs81b/javadocs/index.html. (See the weblogic.management packages.) Configuration Wizard Use the Configuration Wizard to create a new WebLogic Server domain.
1 Overview of WebLogic System Administration For more information, see Creating Domains and Servers. SNMP WebLogic Server includes the ability to communicate with enterprise-wide management systems using Simple Network Management Protocol (SNMP). The WebLogic Server SNMP capability enables you to integrate management of WebLogic Servers into an SNMP-compliant management system that gives you a single view of the various software and hardware resources of a complex, distributed system.
Resources You Can Manage in a WebLogic Server Domain You can also configure a special domain log that contains a definable subset of log messages from all WebLogic Server instances in a domain. You can modify which logged messages from a local server appear in the domain log using the system administrating tools. You can view this domain log using the Administration Console or a text editor/viewer. For more information, see Domain Log Filters at http://e-docs.bea.
1 Overview of WebLogic System Administration Servers The administrative concept of a server represents an instance of WebLogic Server in your domain. Using the system administration tools you can: ! Start and stop servers. (To start and stop servers on a remote machine, you must have Node Manager installed on the remote machine.) For more information see “Node Manager” on page 1-11. ! Configure a server’s connections: ports, HTTP settings, jCom settings, and time outs.
Resources You Can Manage in a WebLogic Server Domain Machines The administrative concept of a machine represents the physical machine that hosts an instance of WebLogic Server. WebLogic Server uses machine names to determine the optimum server in a cluster to which certain tasks, such as HTTP session replication, are delegated. Using the system administration tools you can define one or more machines, configure Node Manger for those machines, and assign servers to the machines.
1 Overview of WebLogic System Administration JMS The Java Message Service (JMS) is a standard API for accessing enterprise messaging systems that allow communication between applications.
Resources You Can Manage in a WebLogic Server Domain Web Servers and Web Components WebLogic Server can perform as a fully functional Web server. WebLogic Server can server both static files such as HTML files and dynamic files such as Java servlets or Java ServerPages (JSP). Virtual hosting is also supported. For more information on managing Web server functionality in WebLogic Server, see “Configuring WebLogic Server Web Components” on page 7-1.
1 Overview of WebLogic System Administration ! Web Applications ! Enterprise JavaBeans (EJB) ! Enterprise Applications ! J2EE Connectors ! Web Services. Web services are deployed as a Web Application that includes a special deployment descriptor that configures the Web Service.
Resources You Can Manage in a WebLogic Server Domain Startup and Shutdown Classes A startup class is a Java program that is automatically loaded and executed when a WebLogic Server is started or restarted and after other server initialization tasks have completed. A shutdown class is automatically loaded and executed when a WebLogic Server is shut down either from the Administration Console or using the weblogic.Admin shutdown command.
1 Overview of WebLogic System Administration ! Programming WebLogic JTA XML The XML Registry is a facility for configuring and administering the XML resources of an instance of WebLogic Server. XML resources in WebLogic Server include the parser used by an application to parse XML data, the transformer used by an application to transform XML data, external entity resolution, and caching of external entities. For more information, see Administering WebLogic Server XML at http://e-docs.bea.
Starting and Using the Administration Console WebLogic Tuxedo Connector WebLogic Tuxedo Connector provides interoperability between WebLogic Server applications and Tuxedo services. The connector allows WebLogic Server clients to invoke Tuxedo services and Tuxedo clients to invoke WebLogic Server Enterprise Java Beans (EJBs) in response to a service request. For more information see WebLogic Tuxedo Connector at http://e-docs.bea.com/wls/docs81b/wtc.html.
1 Overview of WebLogic System Administration Browser Support for the Administration Console To run the Administration Console, use one of the following Web browsers: ! Microsoft Internet Explorer, version 5 on Windows ! Microsoft Internet Explorer, version 6 on Windows ! Netscape, version 4.7 on Windows or SunOS ! Netscape, version 6, on Windows or SunOS If you use a Web browser that is not on the above list you may experience functional or formatting problems.
Using WebLogic Server with Web Servers Using the security system, you can add or delete users to one of these groups to provide controlled access to the console. For more information, see “Protecting System Administration Operations” on page 8-1. Note: If you have your browser configured to send HTTP requests to a proxy server, then you may need to configure your browser to not send Administration Server HTTP requests to the proxy.
1 Overview of WebLogic System Administration ! Configure Proxy Plug-ins at http://e-docs.bea.com/wls/docs81b/plugins/http_proxy.html. ! Proxying Requests to a WebLogic Cluster at http://e-docs.bea.com/wls/docs81b/cluster/setup.html#proxyplugi ns. Monitoring The system administration tools contain extensive capabilities for monitoring WebLogic Servers, domains, and resources.
Licenses ! " Servlet sessions " Connector connection pools " EJB performance JDBC connections and connection pools For more information, see Monitoring a WebLogic Server Domain at http://e-docs.bea.com/wls/docs81b/adminguide/monitoring.html Licenses WebLogic Server requires a valid license to function. An evaluation copy of WebLogic Server is enabled for 30 days so you can start using WebLogic Server immediately.
1 1-26 Overview of WebLogic System Administration Configuring and Managing WebLogic Server
CHAPTER 2 Overview of WebLogic Server Domains The following sections describe WebLogic Server domains and their contents: ! “What Is a Domain?” on page 2-1 ! “Domain Restrictions” on page 2-7 What Is a Domain? A domain is the basic administration unit for WebLogic Server instances. A domain consists of one or more WebLogic Server instances (and their associated resources) that you manage with a single Administration Server.
2 Overview of WebLogic Server Domains Contents of a Domain A domain can include multiple WebLogic Server clusters and non-clustered WebLogic Server instances. Strictly speaking, a domain could consist of only one WebLogic Server instance—however, in that case that sole server instance would be an Administration Server, because each domain must have exactly one Administration Server.
What Is a Domain? Administration Server Each WebLogic Server domain must have one server instance that acts as the Administration Server. You use the Administration Server, programmatically or via the Administration Console, to configure all other server instances and resources in the domain. Role of the Administration Server Before you start the Managed Servers in a domain, you start the Administration Server.
2 Overview of WebLogic Server Domains For more information about the Administration Server and its role in the WebLogic Server JMX management system, see “System Administration Tools” in the Administration Guide. What Happens if the Administration Server Fails? The failure of an Administration Server for a domain does not affect the operation of Managed Servers in the domain.
What Is a Domain? You can create a non-clustered Managed Server and add it to a cluster by configuring pertinent configuration parameters for the server instance and the cluster. Conversely, you can remove a Managed Server from a cluster by re-configuring the parameters appropriately. The key difference between clustered and non-clustered Managed Servers is support for failover and load balancing—these features are available only in a cluster of Managed Servers.
2 Overview of WebLogic Server Domains ! connectors, startup classes, ! JDBC connection pools, ! JMS servers Common Domain Types There are two basic types of domains: ! Domain with Managed Servers: A simple production environment can consist of a domain with several Managed Servers that host applications, and an Administration Server to perform management operations.
Domain Restrictions Domain Restrictions Many WebLogic Server installations consist of a single domain that includes all the Managed Servers required to host applications. If you create more than one domain, note the following restrictions: ! Each domain requires its own Administration Server for performing management activities.
2 Overview of WebLogic Server Domains Domain Directories Structure In prior releases of WebLogic Server, domain directories were created within the directory structure of the Weblogic Server installation. With WebLogic Server 7.0 and later, you can set up domain directories outside the product installation directory tree, in any location on the system that can access the Weblogic Server installation and the JDK. This new directory structure is more flexible.
Domain Restrictions You can use the Configuration Wizard to create and configure domains. At the end of a custom installation, you are prompted to run the Configuration Wizard. You can also start the Configuration Wizard from the Start menu or by using a script. For more information, see Creating Domains and Servers. When you use the Configuration Wizard to create a domain, it creates the user_projects directory in the BEA Home directory as a container for your domains.
2 Overview of WebLogic Server Domains Figure 2-1 Root Directory for WebLogic Server Instances Root Directory for Administration Server Administration Server config.xml Security data context Runtime data Contact Administration Server for security and configuration data Root Directory for Managed Server Managed Server context Runtime and replicated data Multiple instances of WebLogic Server can use the same root directory.
Domain Restrictions ! If -Dweblogic.RootDirectory=path is not specified, and if the working directory (that is, the directory from which you issue the startup command) contains a config.xml file, then the working directory is the root directory. ! If neither of the previous statements is true, then the server looks for a config.xml file in working-directory/config/domain-name. If it finds config.xml in this directory, then working-directory/config/domain-name is the root directory.
2 2-12 Overview of WebLogic Server Domains Configuring and Managing WebLogic Server
CHAPTER 3 Overview of Node Manager The Managed Servers in a production WebLogic Server environment are often distributed across multiple machines and geographic locations. Node Manager is a stand-alone Java utility, provided with WebLogic Server, that allows you to perform common operations tasks for a Managed Server, regardless of its location with respect to its Administration Server. If you run Node Manager on a machine that hosts Managed Servers, you can start and stop the Managed Servers remotely.
3 Overview of Node Manager ! Start and stop remote Managed Servers. ! Monitor the self-reported health of Managed Servers and automatically kill server instances whose health state is “failed”. ! Automatically restart Managed Servers that have the “failed” health state, or have shut down unexpectedly due to a system crash or reboot.
Node Manager Architecture and Environment Figure 3-1 Node Manager Architecture Node Manager Runs on Machines that Host Managed Servers To take advantage of Node Manager capabilities, you must run a Node Manager process on each machine that hosts Managed Servers. You can manage multiple Managed Servers on a single machine with one Node Manager process—in Figure 3-1, the two Managed Servers on Machine C can be controlled by a single Node Manager process.
3 Overview of Node Manager development environment, you may wish to run Node Manager on a machine that hosts an Administration Server and one or more Managed Servers, because doing so allows you to start and stop the Managed Servers using the Administration Console. Node Manager Should Run as a Service The WebLogic Server installation process installs Node Manager to run as a daemon on UNIX machines or as a Windows service on Windows-based machines.
Node Manager Capabilities Node Manager Uses SSL Communication between Node Manager and Managed Servers, Administration Servers, or other clients requires two-way Secure Socket Layer (SSL) protocol, which provides authentication and encryption. Node Manager uses two-way SSL to verify the identity of Managed Servers that communicate with it. You cannot use Node Manager features with an unsecured communication protocol.
3 Overview of Node Manager UNKNOWN. Node Manager does not retry the start command. If the Managed Server successfully starts and establishes a connection with Node Manager, the state of the Managed Server is updated appropriately. Node Manager starts a Managed Server in its last runtime state, rather than in the startup mode configured for the server instance. The startup mode for a server instance is configured on the Server—>Configuration—>General tab; by default, the startup mode is RUNNING.
Node Manager Capabilities machine. The Node Manager forwards the request to the target Managed Server for execution. If the Managed Server fails to respond to a shutdown request from the Node Manager, the Node Manager process itself performs the shutdown. Shutdown Failed Managed Servers Node Manager periodically checks the self-reported heath status of Managed Servers that it has started. (For information about how a Managed Server monitors its health, see “Server Self-Health Monitoring” on page 9-2.
3 Overview of Node Manager on Managed Servers while it was down. When Node Manager is restarted, if a Managed Server it was previously monitoring is not running, it will automatically restart it. Prerequisites for Automatic Restart of Managed Servers For Node Manager to restart failed Managed Servers, the behavior must be configured appropriately, as described in “Configure Monitoring, Shutdown and Restart for Managed Servers” on page 4-6.
CHAPTER 4 Configuring, Starting, and Stopping Node Manager Node Manager is a stand-alone utility you can run on machines that host Managed Servers that allows to you start and stop the Managed Servers remotely. Node Manager can also automatically restart a Managed Server after an unexpected failure. For a full discussion of Node Manager functionality, see “Node Manager Capabilities” on page 3-5.
4 Configuring, Starting, and Stopping Node Manager Default Configuration Node Manager is ready-to-run after WebLogic Server installation if you run Node Manager and the Administration Server on the same machine, and use the demonstration SSL configuration. By default, the following behaviors will be configured: ! You can start a Managed Server using Node Manager, via the Administration Console.
Configuring Node Manager a. “Set Up the Node Manager Hosts File” on page 4-3 b. “Reconfigure Startup Service” on page 4-4 c. “Update nodemanager.properties” on page 4-4 d. “Configure a Machine to Use Node Manager” on page 4-5 e. “Configure Managed Server Startup Arguments” on page 4-5 f. “Ensure Administration Server Address is Defined” on page 4-5 ! Configure Node Manager for production security components—By default Node Manager runs with demonstration security components.
4 Configuring, Starting, and Stopping Node Manager Reconfigure Startup Service The WebLogic Server installation process installs Node Manager as a Windows service, or a daemon on UNIX systems. By default, the service starts up Node Manager to listen on localhost:5555. When you configure Node Manager to accept commands from remote systems, you must uninstall the default Node Manager service, and reinstall the Node Manager service, specifying a non-localhost Listen Address.
Configuring Node Manager Configure a Machine to Use Node Manager If Node Manager must accept commands from remote clients, you must create a machine definition for each machine that runs a Node Manager process. A machine definition associates a particular machine with the server instances it hosts, and specifies the connection attributes for the Node Manager process on that machine. You can create a machine definition using the Machine-->Configuration-->Node Manager tab in the Administration Console.
4 Configuring, Starting, and Stopping Node Manager Set the Listen Address using the Server-->Configuration-->General tab in the Administration Console. Configure SSL for Node Manager Communication between Node Manager and an Administration Server uses the Secure Socket Layer (SSL) protocol, configured for two-way SSL. Authentication requires use of the public key infrastructure, including a password-protected private key and a user identify certificate.
Starting and Stopping Node Manager ! “Node Manager Properties” on page 4-10 Starting Node Manager as a Service The WebLogic Server installation process automatically installs Node Manager as a service, so that it starts up automatically when the system boots. This behavior is appropriate for a production environment, as it ensures that Node Manager is available to restart Managed Servers after a machine reboot.
4 Configuring, Starting, and Stopping Node Manager Properties that are specific to a server instance are specified on the The syntax for starting Node Manager is: java [java_property=value ...] -D[nodemanager_property=value] -D[server_property=value] weblogic.NodeManager Note: WebLogic Server 8.1 provides a new wrapper to weblogic.nodeManager.NodeManager. The new wrapper is weblogic.NodeManager In the command line, a java_property indicates a direct argument to the java executable, such as -ms or -mx.
Starting and Stopping Node Manager Note: If you run Node Manager on a UNIX operating system other than Solaris or HP UX, you cannot have any white space characters in any of the parameters that will be passed to the java command line when starting Node Manager. For example, this command fails due to the space character in the name “big iron”. -Dweblogic.Name="big iron" See “Node Manager Properties” on page 4-10 for information about all Node Manager command-line arguments.
4 Configuring, Starting, and Stopping Node Manager Environment Variable Description LD_LIBRARY_ PATH (UNIX only) For HP UX and Solaris systems, must include the path to the native Node Manager libraries.
Starting and Stopping Node Manager Node Manager Property Description weblogic.nodemanager. sslHostNameVerificatio nEnabled Enables or disables Administration Server hostname checks against the nodemanager.hosts file. Default Disable only when using the demonstration certificates, or if you are specifying Node Manager Listen Address as an IP address. weblogic.nodemanager. keyFile The path to the private key file to use for SSL communication with the Administration Server. ./config/demokey.
4 Configuring, Starting, and Stopping Node Manager Node Manager Property Description Default weblogic.nodemanager. startTemplate For UNIX systems, specifies the path of a script file used to start Managed Servers. ./nodemanager.sh weblogic.nodemanager. trustedHosts The path to the trusted hosts file that Node Manager uses. See “Set Up the Node Manager Hosts File” on page 4-3. ./nodemanager.hosts weblogic.nodemanager. weblogicHome Root directory of the WebLogic Server installation.
Troubleshooting Node Manager Troubleshooting Node Manager The following sections describe how to diagnose and correct Node Manager problems. Use the Node Manager log files to help troubleshoot problems in starting or stopping individual Managed Servers. Use the steps in “Correcting Common Problems” on page 4-14 to solve problems in Node Manager configuration and setup.
4 Configuring, Starting, and Stopping Node Manager attempt is made to start the server, this file is renamed by appending _PREV to the file name. The domain’s Administration Server stores a copy of the Managed Server log files in the a directory name NodeManagerClientLogs. This directory is created one directory level above the Administration Server’s root directory (by default, the directory in which you started the server).
Troubleshooting Node Manager . Symptom Explanation Error message: Could not start server 'MyServer' via Node Manager reason: 'Target machine configuration not found'. You have not assigned the Managed Server to a machine. Follow the steps in “Configure a Machine to Use Node Manager” on page 4-5. Error message: The Node Manager process may not be running on the designated machine.
4 Configuring, Starting, and Stopping Node Manager Symptom Explanation Applications on the Managed Server are using the wrong directory for lookups. Applications deployed to WebLogic Server should never make assumptions about the current working directory. File lookups should generally take place relative to the Root Directory obtained with the ServerMBean.getRootDirectory() method (this defaults to the “.” directory).
Troubleshooting Node Manager ! ACTIVATE_LATER—Indicates that MaxRestart restart attempts have been made in current RestartInterval, and Node Manager will attempt additional restarts in the next RestartInterval. ! FAILED_NOT_RESTARTABLE—Indicates that the server is Failed, but Node Manager cannot restart it because the server's AutoRestart or AutoKillIfFailed attribute is set to False.
4 4-18 Configuring, Starting, and Stopping Node Manager Configuring and Managing WebLogic Server
CHAPTER 5 Setting Up a WebLogic Server as a Windows Service If you want a WebLogic Server to start automatically when you boot a Windows host, you can set up the server as a Windows service. For each server that you set up as a Windows service, WebLogic Server creates a key in the Windows Registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. The registry entry contains such information as the name of the server and other startup arguments.
5 Setting Up a WebLogic Server as a Windows Service Setting Up a Windows Service WebLogic Server includes a master script, WL_HOME\server\bin\installSvc.cmd, that you can use to set up a server instance as a Windows Service. Instead of invoking the installSvc.cmd master script directly, create your own script that supplies values for a set of variables and then calls the installSvc.cmd script: 1.
@rem for the server instance requires you to delete the Windows service and set @rem up a new one with the new username and password. @rem If you use a boot identity file to bypass the prompt, you can change the @rem login credentials without needing to modify the Windows service. For more @rem information about bypassing the username and password prompt, refer to @rem "Bypassing the Prompt for Username and Password" in the Administration @rem Console Online Help.
5 Setting Up a WebLogic Server as a Windows Service 2. If you set up both an Administration Server and a Managed Server to run as Windows services on the same computer, you can specify that the Managed Server starts only after the Administration Server has started by doing the following: a. In a text editor, open the WL_HOME\server\bin\installSvc.cmd master script. The last command in this script invokes the beasvc utility. b.
Regardless of whether you choose yes or no, if the domain template includes a prompt for setting up a service, it will create a script named installService.cmd in the server’s root directory, which is similar to the script in Listing 5-1, “Script for Setting Up a Server as a Windows Service,” on page 5-2.
5 Setting Up a WebLogic Server as a Windows Service If your setup was successful, the beasvc -debug command starts your server. If the script returns an error similar to the following, make sure that you specified the correct service name: Unable to open Registry Key .......
@rem The script simply sets the DOMAIN_NAME and SERVER_NAME variables and calls @rem the %WL_HOME%\server\bin\uninstallSvc.cmd script. @rem ************************************************************************* echo off SETLOCAL @rem Set DOMAIN_NAME to the name of the domain that contains the server. set DOMAIN_NAME=myWLSdomain @rem Set SERVER_NAME to the name of the server that you want to remove as @rem a service.
5 Setting Up a WebLogic Server as a Windows Service ! If you set up the Windows service to retrieve usernames and passwords from a boot identity file, you can overwrite the existing file with a new one that contains the new username and password. For information about creating a boot identity file, refer to "Creating a Boot Identity File" in the Administration Console Online Help.
–remove Remove the specified service. –svcname: service_name The user-specified name of the service to be installed or removed. –javahome: java_directory Root directory of the Java installation. The start command will be formed by appending \bin\java to java_directory. –execdir: domain_name Directory where this startup command will be executed. –extrapath: additional_env_settings Additional path settings that will be prepended to the path applicable to this command execution.
5 Setting Up a WebLogic Server as a Windows Service set CMDLINE="-ms64m -mx64m -Dweblogic.Name=myserver -Dbea.home=\"c:\bea\" -classpath @C:\temp\myclasspath.txt weblogic.Server" "c:\bea\weblogic810\server\bin\beasvc" -install -svcname:myserver -cmdline:%CMDLINE% Run the script.
CHAPTER 6 Server Lifecycle 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, the state transitions that can occur, and the relationship between commands that you issue and server state transitions.
6 Server Lifecycle Figure 6-1 The Server Lifecycle To understand the each state, and the relationships among states, see “WebLogic Server States” on page 6-2. 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.
WebLogic Server States ! Monitor the availability of server instances and the applications they host. ! Perform data 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.
6 Server Lifecycle 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.
WebLogic Server States A server instance can enter the STARTING state only from the SHUTDOWN state, as a result of either a Start command or a Start in Standby command. SHUTDOWN→STARTING→RUNNING SHUTDOWN→STARTING→STANDBY For information about issuing start commands, see “Starting and Stopping Servers” in Administration Console Online Help.
6 Server Lifecycle any state→STANDBY→SHUTDOWN RESUMING A server instance enters the RESUMING state as a result of the Resume this server... 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 STANDBY if: ! It is started using the Start this server... command.
WebLogic Server States 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 For more information about the graceful shutdown process, see “Graceful Shutdown” on page 6-9.
6 Server Lifecycle 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” on page 4-16. 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” on page 3-1.
Lifecycle Commands ! Security Service ! JCA Container ! RMI Service ! JDBC Container ! Cluster Service ! EJB Container ! IIOP Service ! Web Container ! Naming Service ! Deployment Manager ! RMI Naming Service ! JMS Provider ! File Service ! Remote Management ! Transaction Service 3. If you have configured a server instance to use a separate administration port, the server enables remote configuration and monitoring.
6 Server Lifecycle 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.
Lifecycle Commands Note: Graceful Shutdown Timeout is a different attribute from ServerLifeCycleTimeoutVal, which applies only to a force shutdown. 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 RMI subsystem suspends in three steps. Each step in this process completes before the following step commences. 1.
6 Server Lifecycle The completion of pending sessions is optional. To immediate drop all sessions, 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.
Lifecycle Commands 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. ServerMBean defines the ServerLifecycleTimeoutVal attribute, which specifies a timeout period for subsystems to suspend themselves. If a subsystem fails to suspend itself within the timeout period, the server instance is killed.
6 6-14 Server Lifecycle Configuring and Managing WebLogic Server
CHAPTER 7 Configuring WebLogic Server Web Components The following sections discuss how to configure WebLogic Server Web components: ! “Overview” on page 7-2 ! “HTTP Parameters” on page 7-2 ! “Configuring the Listen Port” on page 7-4 ! “Web Applications” on page 7-5 ! “Configuring Virtual Hosting” on page 7-7 ! “How WebLogic Server Resolves HTTP Requests” on page 7-10 ! “Setting Up HTTP Access Logs” on page 7-14 ! “Preventing POST Denial-of-Service Attacks” on page 7-22 ! “Setting Up WebL
7 Configuring WebLogic Server Web Components Overview In addition to its ability to host dynamic Java-based distributed applications, WebLogic Server is also a fully functional Web server that can handle high volume Web sites, serving static files such as HTML files and image files as well as servlets and JavaServer Pages (JSP). WebLogic Server supports the HTTP 1.1 standard. HTTP Parameters You can configure the HTTP operating parameters using the Administration Console for each Server or Virtual Host.
HTTP Parameters Attribute Description Range of Values Default Value Send Server Header If set to false, the server name is not sent with the HTTP response. Useful for wireless applications where there is limited space for headers. Boolean True Duration The number of seconds that WebLogic Server waits before closing an inactive HTTP connection. Integer 30 The number of seconds that WebLogic Server waits before closing an inactive HTTPS connection.
7 Configuring WebLogic Server Web Components Attribute Description Range of Values Default Value Max Post Time This attribute sets the time (in seconds) that WebLogic Server waits for chunks of data in an HTTP POST data. Integer 0 Max Post Size This attribute sets the size of the maximum chunks of data in an HTTP POST data.
Web Applications Web Applications HTTP and Web Applications are deployed according to the Servlet 2.3 specification from Sun Microsystems, which describes the use of Web Applications as a standardized way of grouping together the components of a Web-based application. These components include JSP pages, HTTP servlets, and static resources such as HTML pages or image files. In addition, a Web Application can access external resources such as EJBs and JSP tag libraries.
7 Configuring WebLogic Server Web Components Web Applications and Clustering Web Applications can be deployed in a cluster of WebLogic Servers. When a user requests a resource from a Web Application, the request is routed to one of the servers of the cluster that host the Web Application. If an application uses a session object, then sessions must be replicated across the nodes of the cluster. Several methods of replicating sessions are provided.
Configuring Virtual Hosting To designate a default Web Application for a server or virtual host, use the Administration Console: 1. In the left pane, expand the Web Application node 2. Select your Web Application 3. In the right pane, select the Targets tab. 4. Select the Servers tab and move the server (or virtual host) to the chosen column. (You can also target all the servers in a cluster by selecting the Clusters tab and moving the cluster to the Chosen column.) 5. Click Apply. 6.
7 Configuring WebLogic Server Web Components For example, you can specify that a Web Application called books responds to requests for the virtual host name www.books.com, and that these requests are targeted to WebLogic Servers A,B and C, while a Web Application called cars responds to the virtual host name www.autos.com and these requests are targeted to WebLogic Servers D and E.
Configuring Virtual Hosting Setting Up a Virtual Host To define a virtual host, use the Administration Console to: 1. Create a new Virtual Host. a. Expand the Services node in the left pane. The node expands and displays a list of services. b. Click on the virtual hosts node. If any virtual hosts are defined, the node expands and displays a list of virtual hosts. c. Click on Create a New Virtual Host in the right pane. d. Enter a name to represent this virtual host. e.
7 Configuring WebLogic Server Web Components a. Select the Targets tab. b. Select the Clusters tab. You will see a list of available servers. c. Select a cluster in the available column and use the right arrow button to move the cluster to the chosen column. The virtual host is targeted on all of the servers of the cluster. 5. Target Web Applications to the virtual host. a. Click the Web Applications node in the left panel. b. Select the Web Application you want to target. c.
How WebLogic Server Resolves HTTP Requests The table below provides some sample URLs and the file that is served by WebLogic Server. The Index Directories Checked column refers to the Index Directories attribute that controls whether or not a directory listing is served if no file is specifically requested. You set Index Directories using the Administration Console, on the Web Applications node, under the Configuration →Files tab.
7 Configuring WebLogic Server Web Components Table 7-1 Examples of How WebLogic Server Resolves URLs URL Index Directories Checked? This file is served in response http://host:port/naval Does not matter Servlet mapped with of /naval in the oranges Web Application and oranges is defined as the default Web Application. For more information, see Configuring Servlets at http://e-docs.bea.c om/wls/docs81b/weba pp/ components.html #configuringservlets. http://host:port/apples/pie.
How WebLogic Server Resolves HTTP Requests Table 7-1 Examples of How WebLogic Server Resolves URLs URL Index Directories Checked? This file is served in response http://host:port/myFile.html Does not matter Error 404 Where myfile.html does not exist in the apples Web Application and a default servlet has not been defined. For more information, see Customizing HTTP Error Responses at http://e-docs.bea.c om/wls/docs81b/weba pp/components.html# error-page. http://www.fruit.
7 Configuring WebLogic Server Web Components Setting Up HTTP Access Logs WebLogic Server can keep a log of all HTTP transactions in a text file, in either common log format or extended log format. Common log format is the default, and follows a standard convention. Extended log format allows you to customize the information that is recorded. You can set the attributes that define the behavior of HTTP access logs for each server or for each virtual host that you define.
Setting Up HTTP Access Logs RFC931 Any information returned by IDENTD for the remote client; WebLogic Server does not support user identification auth_user If the remote client user sent a userid for authentication, the user name; otherwise “-” day/month/year:hour:minute:second UTC_offset Day, calendar month, year and time of day (24-hour format) with the hours difference between local time and GMT, enclosed in square brackets "request" First line of the HTTP request submitted by the remote client enclo
7 Configuring WebLogic Server Web Components Creating the Fields Directive The first line of your log file must contain a directive stating the version number of the log file format. You must also include a Fields directive near the beginning of the file: #Version: 1.0 #Fields: xxxx xxxx xxxx ... Where each xxxx describes the data fields to be recorded. Field types are specified as either simple identifiers, or may take a prefix-identifier format, as defined in the W3C specification.
Setting Up HTTP Access Logs The following identifiers require prefixes, and cannot be used alone. The supported prefix combinations are explained individually. IP address related fields: These fields give the IP address and port of either the requesting client, or the responding server. This field has type
, as defined in the W3C specification. The supported prefixes are: c-ip The IP address of the client. s-ip The IP address of the server.7 Configuring WebLogic Server Web Components cs-uri-query Only the query portion of the URI. This field has type , as defined in the W3C specification. Creating Custom Field Identifiers You can also create user-defined fields for inclusion in an HTTP access log file that uses the extended log format. To create a custom field you identify the field in the ELF log file using the Fields directive and then you create a matching Java class that generates the desired output.
Setting Up HTTP Access Logs http://e-docs.bea.com/wls/docs81b/javadocs/weblogic/servlet/ logging/FormatStringBuffer.html). 3. Compile the Java class and add the class to the CLASSPATH statement used to start WebLogic Server. You will probably need to modify the CLASSPATH statements in the scripts that you use to start WebLogic Server. Note: Do not place this class inside of a Web Application or Enterprise Application in exploded or jar format. 4. Configure WebLogic Server to use the extended log format.
7 Configuring WebLogic Server Web Components Table 7-2 Getter Methods of HttpAccountingInfo HttpAccountingInfo Methods Where to find information on the methods int getResponseContentLength(); javax.servlet.ServletResponse. setContentLength() This method gets the content length of the response, as set with the setContentLength() method. String getContentType(); javax.servlet.ServletRequest Locale getLocale(); javax.servlet.ServletRequest Enumeration getLocales(); javax.servlet.
Setting Up HTTP Access Logs Table 7-2 Getter Methods of HttpAccountingInfo HttpAccountingInfo Methods Where to find information on the methods Enumeration getHeaders(String name); javax.servlet.http.Http.ServletRequest int getIntHeader(String name); javax.servlet.http.Http.ServletRequest String getMethod(); javax.servlet.http.Http.ServletRequest String getPathInfo(); javax.servlet.http.Http.ServletRequest String getPathTranslated(); javax.servlet.http.Http.
7 Configuring WebLogic Server Web Components Listing 7-1 Java Class for Creating a Custom ELF Field import weblogic.servlet.logging.CustomELFLogger; import weblogic.servlet.logging.FormatStringBuffer; import weblogic.servlet.logging.HttpAccountingInfo; /* This example outputs the User-Agent field into a custom field called MyCustomField */ public class MyCustomField implements CustomELFLogger{ public void logField(HttpAccountingInfo metrics, FormatStringBuffer buff) { buff.appendValueOrDash(metrics.
Setting Up WebLogic Server for HTTP Tunneling MaxPostSize Limits the number of bytes of data received in a POST from a single request. If this limit is triggered, a MaxPostSizeExceeded exception is thrown and the following message is sent to the server log: POST size exceeded the parameter MaxPostSize. An HTTP error code 413 (Request Entity Too Large) is sent back to the client. If the client is in listening mode, it gets these messages. If the client is not in listening mode, the connection is broken.
7 Configuring WebLogic Server Web Components Enable Tunneling Enables or disables HTTP tunneling. HTTP tunneling is disabled by default. Note that the server must also support both the HTTP and T3 protocols in order to use HTTP tunneling. Tunneling Client Ping When an HTTP tunnel connection is set up, the client automatically sends a request to the server, so that the server may volunteer a response to the client.
Using Native I/O for Serving Static Files (Windows Only) The client must specify the port in the URL, even if the port is 80. You can set up your WebLogic Server to listen for HTTP requests on any port, although the most common choice is port 80 since requests to port 80 are customarily allowed through a firewall. You specify the listen port for WebLogic Server in the Administration Console under the “Servers” node, under the “Network” tab.
7 Configuring WebLogic Server Web Components weblogic.http.nativeIOEnabled TRUE weblogic.http.minimumNativeFileSize 500 For more information on writing deployment descriptors, see Writing Web Application Deployment Descriptors at http://e-docs.bea.com/wls/docs81b/webapp/deployment.html.
CHAPTER 8 Protecting System Administration Operations To leverage individual skills, many Web development teams divide system administration responsibilities into distinct roles. Each project might give only one or two team members permission to deploy components, but allow all team members to view the WebLogic Server configuration.
8 Protecting System Administration Operations Operations Available to Each Role Table 8-1 describes the four global roles that WebLogic Server uses to determine access privileges for system administration operations, and the permissions granted to each role. Table 8-1 Global Roles and Permissions Global Role Permissions Admin View the server configuration, including the encrypted value of encrypted attributes. Modify the entire server configuration.
Operations Available to Each Role While you can create any number of additional roles for use in your applications, only the roles in Table 8-1 have permission to view or change the configuration of a WebLogic Server. To define a role, use the Administration Console. For more information, refer to Granting Roles in the Managing WebLogic Security guide. Default Group Associations By default, a WebLogic Server defines four groups that correspond to the four global roles.
8 Protecting System Administration Operations Figure 8-1 Relationship of Group and Role Membership Members of Role Calculated membership based on user ID or group ID and time/date. Static list of user IDs Static list of additional groups Members of Corresponding Group Static list of group and user IDs For example, if you add a user to the group named Deployers, by default the user will also belong to the Deployer role.
Overlapping Permissions for System Administration MBeans and Policies on Resourc! The Administration Console. For information about using this UI, refer to the Administration Console Online Help. Note: To use the Administration Console, you must belong to one of the groups and roles that are described in Table 8-2. The other user interfaces do not require you to belong to one of the default groups. ! The weblogic.Admin command. For information about using this UI, refer to "weblogic.
8 Protecting System Administration Operations Resources and Policies A WebLogic Server instance, the server’s subsystems (such as Deployment Manager and JDBC Container), and the items that the subsystems control (such as Web applications and JDBC connection pools) are called resources. Each WebLogic Server resource exposes a set of its operations through its own instance of the weblogic.security.spi.Resource interface.
Overlapping Permissions for System Administration MBeans and Policies on Resourc- Working with Policies You can view, create, or modify policies on resources from the Administration Console. For example, to view the policy on a server resource, right click the name of a WebLogic Server and choose Define Policy. As illustrated in Figure 8-3, the default policy for a server resource grants access to the Admin and Operator role.
8 Protecting System Administration Operations Maintaining a Consistent Security Scheme The default configuration of groups, roles, server policies, and MBean permissions work together to create a consistent security scheme. You can, however, make modifications that limit access in ways that you do not intend.
Permissions for Starting and Shutting Down a WebLogic Server ! Shutting Down a WebLogic Server Permissions for Using the weblogic.Server Command The weblogic.Server command, which starts a WebLogic Server from a local host machine, calls methods that are protected by a policy on the server resource. To use this command, you must satisfy the requirements of the policy on the server. Some weblogic.Server arguments set attributes for MBeans.
8 Protecting System Administration Operations Shutting Down a WebLogic Server Shutting down a WebLogic Server also involves both MBeans and the server resource. When you issue a shutdown command, the server first determines whether you are a member of the Admin or Operator role (per the MBean security scheme). Then, after the MBean operations run, the server determines whether the policy on the server resource authorizes you to shut down the server.
CHAPTER 9 Monitoring a WebLogic Server Domain These sections describe WebLogic Server monitoring capabilities that help you manage and optimize application availability, performance, and security: ! “Facilities for Monitoring WebLogic Server” on page 9-1 ! “Monitoring WebLogic Server using the Administration Console” on page 9-5 Facilities for Monitoring WebLogic Server These sections describe WebLogic Server facilities for monitoring the health and performance of a WebLogic Server domain: ! “Adminis
9 Monitoring a WebLogic Server Domain The Administration Console obtains information about domain resources from the domain’s Administration Server. The Administration Server is populated with Management Beans (MBeans), based on Sun’s Java Management Extension (JMX) standard, which provides the scheme for management access to domain resources.
Facilities for Monitoring WebLogic Server Obtaining Server Health Programmatically You can check the self-reported health state of a server instance programmatically by calling the getHealthState() method on the ServerRuntimeMBean. Similarly, you can obtain the health state of a registered WebLogic Server subsystem by calling the getHealthState() method on its MBean.
9 Monitoring a WebLogic Server Domain If you start a Managed Server with Node Manager, Node Manager redirects the server instance’s standard error to a file. In this case, you can view the Managed Server’s output using Domain→Server→Remote Start Output→View Server error output. 9-4 ! Server Logs—Each WebLogic Server instance writes all messages from its subsystems and applications to a log file on its host machine. You can configure logging behavior using the Server→Logging→Server tab.
Monitoring WebLogic Server using the Administration Console Monitoring WebLogic Server using the Administration Console The left pane of the Administration Console is a tree control, with a node for key entities you have configured.
9 Monitoring a WebLogic Server Domain Console Page Attributes Displayed Domain→Monitor→Cluster ! Name ! Cluster Status ! Cluster Address ! Multicast Address ! Multicast Send Delay ! Configure Server Count ! Good Server Count ! Bad Server Count Other Domain Monitoring Links Each domain-level monitoring page has links to display: ! Domain Log—The Domain Log contains messages forwarded by all server instances in the domain.
Monitoring WebLogic Server using the Administration Console Console Page Attributes Displayed Domain→Server→Monitoring→ General ! State Activation Time ! WebLogic Version ! JDK Vendor ! JDK Version ! Operating System ! OS Version Domain→Server→Monitoring→ ! Idle Threads Performance ! Oldest Pending Request ! Throughput ! Queue Length ! Memory Usage ! Total Users Locked Out ! Total Invalid Logins ! Total Login Attempts while Locked ! Total Users Unlocked ! Invalid Logins
9 Monitoring a WebLogic Server Domain Console Page Attributes Displayed Domain→Server→Monitoring→ JMS ! Current Connections ! Connections High ! Total Connections ! Current JMS Servers ! Servers High ! Servers Total ! Total Transactions ! Total Committed ! Total Rolled Back ! Timeout Rollbacks ! Resource Rollbacks ! Application Rollbacks ! System Rollbacks ! Total Heuristics ! Total Transactions Abandoned ! Average Commit Time Domain→Server→Monitoring→ JMS Monitor all Ac
Monitoring WebLogic Server using the Administration Console Console Page Attributes Displayed Transaction by Name ! Pooled Beans Current Count ! Beans in Use Current Count ! Access Total Count ! Miss Total Count ! Cache Access Count ! Cache Hit Count ! Cache Miss Count ! Name ! Transactions ! Commits ! Rollbacks ! Heuristics ! Heuristic Commits ! Heuristic Rollbacks ! Mixed Heuristics ! Heuristic Hazards ! Transaction Id ! Name ! Status ! Seconds Active ! Servers
9 Monitoring a WebLogic Server Domain Console Page Attributes Displayed Domain→Server→Remote Start Output→View Node Manager output... If the server instance was started by Node Manager, the Node Manager log can be viewed with this link.
Monitoring WebLogic Server using the Administration Console . Console Page Attributes Displayed Domain→Cluster→Monitoring ! Number of Servers configured for this cluster ! Number of Servers currently participating in this cluster ! Name ! State ! Servers ! Resend Requests ! Fragments Received ! Lost Multicast Messages Machines Monitoring Pages The following table lists the monitoring pages available for a machine, and the attributes displayed on each page. .
9 Monitoring a WebLogic Server Domain Deployments Monitoring Pages The following table lists the monitoring pages available in the Deployments Node, and the attributes displayed on each page .
Monitoring WebLogic Server using the Administration Console Console Page Attributes Displayed EJB --> Monitoring --> Entity EJBs ! Pooled Beans Current Count ! Beans in Use Current Count ! Access Total Count ! Miss Total Count ! Cache Access Count ! Cache Hit Count ! Cache Miss Count ! Server ! Context Root ! Servlets ! Sessions ! Sessions High ! Total Sessions ! Servlet Name ! Server ! Invocation Total Count ! Execution Time Average Web Applications→Monitoring→Web Appl
9 Monitoring a WebLogic Server Domain Services Monitoring Pages The following table lists the monitoring pages available in the Services node, and the attributes displayed on each page.
Monitoring WebLogic Server using the Administration Console Console Page Attributes Displayed JMS Queues Configuring and Managing WebLogic Server 9-15
9 9-16 Monitoring a WebLogic Server Domain Configuring and Managing WebLogic Server
CHAPTER 10 Recovering Failed Servers A variety of events can lead to the failure of a server instance. Often one failure condition leads to another. Loss of power, hardware malfunction, operating system crashes, network partitions, and unexpected application behavior can all contribute to the failure of a server instance. Depending on availability requirements, you may implement a clustered architecture to minimize the impact of failure events.
10 Recovering Failed Servers Automatic Restart for Managed Servers WebLogic Server provides self-health monitoring to improve the reliability and availability of server instances in a domain. Selected subsystems within each WebLogic Server instance monitor their health status based on criteria specific to the subsystem. (For example, the JMS subsystem monitors the condition of the JMS thread pool while the core server subsystem monitors default and user-defined execute queue statistics.
WebLogic Server Failure Recovery Features Managed Server in MSI mode always looks for a configuration file named msi-config.xml.) ! SerializedSystemIni.dat ! boot.properties—an optional file that contains an encrypted version of your username and password. For more information, “Bypassing the Prompt for Username and Password” in the Administration Console Online Help.
10 Recovering Failed Servers MSI Mode and SSL If you set up SSL for your servers, each server requires its own set of certificate files, key files, and other SSL-related files. Managed Servers do not retrieve SSL-related files from the Administration Server (though the domain’s configuration file does store the pathnames to those files for each server). Starting in MSI Mode does not require you to copy or move the SSL-related files unless they are located on a machine that is inaccessible.
Backing Up Configuration and Security Data To enable a Managed Server to replicate the domain's configuration files, see “Replicating a Domain's Configuration Files for Managed Server Independence” in Administration Console Online Help. MSI Mode and Restored Communication with an Administration Server When the Administration Server starts, it can detect the presence of running Managed Servers (if -Dweblogic.management.discover=true, which is the default setting for this property).
10 Recovering Failed Servers Backing up config.xml By default, an Administration Server stores a domain’s configuration data in a file called domain_name\config.xml, where domain_name is the root directory of the domain. Backup config.xml to a secure location in case a failure of the Administration Server renders the original copy unavailable. If an Administration Server fails, you can copy the backup version to a different machine and restart and Administration Server on the new machine.
Backing Up Configuration and Security Data The new file, WL_HOME\samples\server\config\medrec\config.xml, represents the MedRec domain with the new server instance. The previous file, WL_HOME\samples\server\config\medrec\configArchive\config.xml#2, contains the MedRec domain configuration as it was prior to creation of the new server instance. The next time you change the configuration, MedRecServer saves the current config.xml file as config.xml#3.
10 Recovering Failed Servers Example of Archives of config.xml During Startup If your domain configuration is stored in config.xml, when you start the domain’s Administration Server, the Administration Server: 1. Copies config.xml to config.xml.original. 2. Parses config.xml. Depending on the domain configuration, some WebLogic subsystems add configuration information to config.xml. For example, the Security service adds MBeans and encrypted data for SSL communication. 3.
Backing Up Configuration and Security Data providers cannot modify security data while the domain’s Administration Server is unavailable. The LDAP repositories on Managed Servers are replicas and cannot be modified. The ldap/ldapfiles subdirectory contains the data files for the LDAP server. The files in this directory contain user, group, group membership, policies, and role information. Other subdirectories under the ldap directory contain LDAP server message logs and data about replicated LDAP servers.
10 Recovering Failed Servers Restarting Failed Server Instances The nature of your applications and user demand determine the steps you take to restore application service.
Restarting Failed Server Instances Restarting an Administration Server When Managed Servers are Running If the Administration Server shuts down while Managed Servers continue to run, you do not need to restart the Managed Servers that are already running in order to recover management of the domain. The procedure for recovering management of an active domain depends upon whether you can restart the Administration Server on the same machine it was running on when the domain was started.
10 Recovering Failed Servers 2. Make your application files available to the new Administration Server by copying them from backups or by using a shared disk. Your application files should be available in the same relative location on the new file system as on the file system of the original Administration Server. 3. Make your configuration and security data available to the new administration machine by copying them from backups or by using a shared disk.
Restarting Failed Server Instances Starting a Managed Server When the Administration Server Is Not Accessible If a Managed Server cannot connect to the Administration Server during startup, it can retrieve its configuration by reading locally cached configuration data. A Managed Server that starts in this way is running in Managed Server Independence (MSI) mode.
10 Recovering Failed Servers Additional Failure Topics For information related to recovering JMS data from a failed server instance, see “Configuring JMS Migratable Targets” in Programming WebLogic JMS. For information about transaction recovery after failure, see “Moving a Server to Another Machine” and “Transaction Recovery After a Server Fails” in Administration Console Online Help.
CHAPTER 11 Configuring Network Resources WebLogic Server allows you to manage the connection behavior of the server instances that host applications. Configurable resources, including Network Channels and domain-wide administration ports, help you effectively utilize the network features of the machines that host your applications and manage quality of service.
11 Configuring Network Resources WebLogic Server allows you to control the network traffic associated with your applications in a variety of ways, and configure your environment to meet the varied requirements of your applications and end users. You can: ! Designate the NICS and ports used by Managed Servers and for different types of network traffic. ! Prioritize traffic by server instance or type of traffic. ! Support multiple protocols and security requirements.
Understanding Network Channels What is a Channel? A Network Channel is a configurable resource that defines the attributes of a network connection to WebLogic Server. For instance, a Network Channel can define: ! The protocol the connection supports. ! The listen address. ! The listen ports for secure and non-secure communication. ! Connection properties such as the login timeout value and maximum message sizes. ! Whether or not the connection supports tunneling.
11 Configuring Network Resources ServerMBean and SSLMBean represent a server instance and its SSL configuration. When you configure a server instance’s Listen Address, Listen Port, and SSL Listen port, using the Server-->Configuration-->General tab, those values are stored in the ServerMBean and SSLMBean for the server instance. If you do not specify a particular connection attribute in a custom channel definition, the channel inherits the value specified for the attribute in ServerMBean.
Understanding Network Channels guaranteed level of throughput, by assigning the highest weighting to an outbound channel that utilizes a fast NIC. Note: Network channel weights apply only to internal connections made for remote references, such as a remote EJB reference or a resource located via JNDI. Channel weights are not used for connections initiated directly via a URL.
11 Configuring Network Resources Note: The default channel and administration channel, derived from values in the ServerMBean and SSLMBean, are always considered for outgoing connections, and use a default weight of 50. Handling Channel Failures Although WebLogic Server always attempts to use the highest-weighted channels before lower-weighted ones, a network failure may render the selected channel unavailable.
Understanding Network Channels Standard WebLogic Server Channels WebLogic Server provides pre-configured channels that you do not have to explicitly define. ! Default channel—Every Managed Server has a default channel. ! Administrative channel—If you configure a domain-wide Administration Port, WebLogic Server configures an Administrative Channel for each Managed Server in the domain.
11 Configuring Network Resources Administration Port Capabilities An administration port provides these capabilities: ! It enables you to start a server in standby state. This allows you to administer a Managed Server, while its other network connections are unavailable to accept client connections. For more information on the standby state, see “STANDBY” on page 6-5. ! It enables you to separate administration traffic from application traffic in your domain.
Understanding Network Channels ! After you enable the administration port, you must establish an SSL connection to the Administration Server in order to start any Managed Server in the domain. This applies whether you start Managed Servers manually, at the command line, or using Node Manager. For instructions to establish the SSL connection, see “Booting Managed Servers to use Administration Port” on page 11-9.
11 Configuring Network Resources If the hostname in the URL is is not identical to the hostname in the Administration Server’s certificate, disable hostname verification in the command line or start script, as shown below: -Dweblogic.security.SSL.ignoreHostnameVerification=true Configuring a Channel You can configure a Network Channel using Servers-->Protocols-->Channels tab in the Administration Console or using the NetworkChannelMBean.
Configuring a Channel ! Some protocols do not support particular features of channels. In particular the COM protocol does not support SSL or tunneling. ! You must define a separate channel for each protocol you wish the server instance to support, with the exception of HTTP. HTTP is enabled by default when you create a channel, because RMI protocols typically require HTTP support for downloading stubs and classes.
11 11-12 Configuring Network Resources ! For each channel you want to use in the cluster, configure the channel identically, including its name, on each Managed Server in the cluster. ! Make sure that the Listen Port and SSL Listen Port you define for each Managed Server’s channel are different than the Managed Server’s default listen ports.
CHAPTER A Starting and Stopping Servers: Quick Reference The following sections describe simple, frequently used ways to start and shut down instances of WebLogic Server: ! “Starting Instances of WebLogic Server” on page A-2 ! “Shutting Down Instances of WebLogic Server” on page A-4 For a comprehensive discussion of starting and shutting down WebLogic Server instances, refer to "Starting and Stopping Servers.
A Starting and Stopping Servers: Quick Reference Starting Instances of WebLogic Server In the following table, WL_HOME refers to the directory in which you installed the WebLogic Server software. Table 11-1 Starting Server Instances To Start Do The Following The MedRecServer sample server Invoke the following command: WL_HOME\samples\server\config\startMedRecServer.cmd (Windows) WL_HOME\samples\server\config\startMedRecServer.
Starting Instances of WebLogic Server Table 11-1 Starting Server Instances To Start Do The Following A Managed Server that you Do the following: create 1. Start the domain’s Administration Server. 2. Configure the Managed Server to communicate with a Node Manager. For more information, refer to “Configuring a Machine.” 3. Start the Node Manager on the computer that you want to host the Managed Server. For more information, refer to "Starting Node Manager." 4. Start the domain’s Administration Console.
A Starting and Stopping Servers: Quick Reference Shutting Down Instances of WebLogic Server The recommended procedure for shutting down a server is as follows: 1. Start the domain’s Administration Console. For more information, refer to "Starting the Administration Console" 2. In left pane of the Administration Console, expand the Servers folder. 3. Click on the name of a server. (See Figure 11-1.) 4. In the right pane, select the Control tab. Then select the Start/Stop tab. 5.
Index A E access logs 7-14 Administration Console read-only access 8-2 stopping WebLogic Servers from A-4 Administration Server restarting 10-10, 10-11 role in monitoring domain 9-2 evaluation license 1-25 extended log format 7-14 B beasvc.exe 5-8 C common log format 7-14 Concurrent 9-10 config.
monitoring 9-14 JRockitRuntime JRockit Concurrent 9-10 Gc Algorithm 9-10 GCHandles Compaction 9-10 Generational 9-10 Incremental 9-10 Max Heap Size 9-10 Number Of Daemon Threads 9-10 Number Of Processors 9-10 Parallel 9-10 Total Garbage Collection Count 9-10 Total Number Of Threads 9-10 Total Nursery Size 9-10 JVM (Java Virtual Machine), using a nondefault 5-5 L license evaluation 1-25 listen port 7-4 Number Of Processors 9-10 P Parallel 9-10 platform support for Node Manager 3-5 POST method 7-22 PostTim
W Web Application 7-5 default Web Application 7-6 URL 7-11 Windows Service starting WebLogic Server as 5-6 Windows service removing WebLogic Server as 5-6 Configuring and Managing WebLogic Server I--3
