Excerpt: The key concepts of Oracle WebLogic server

Important WebLogic Server Concepts

In order to fully comprehend how WebLogic Server works and to get the best performance out of it, it's important to understand several concepts. The most important concepts are discussed in the following section.

Execute Threads and Queues

This section briefly describes the internal architecture of Oracle WebLogic Server in the sense of how the server performs its work of satisfying user requests. When a client sends a request to the WebLogic Server, the actual work to satisfy that request is performed by a Java thread called an execute thread. A user can submit work to WebLogic Server using an HTTP-based request to the Servlet engine or a request for Remote Method Invocation (RMI) access to objects such as Enterprise JavaBeans (EJBs). When a server process starts up, it binds itself to a port and assigns a listen thread to the port to listen for incoming requests. Once the request makes a connection, the server passes the control of that connection to the socket muxer. The socket muxer reads requests off the socket and places the work requests into the self-tuning execute queue as they arrive. An idle execute thread will pick up a request from the execute queue and may in turn hand off the job of responding to those requests to special threads. The execute thread executes the requests and returns the responses.

Oracle WebLogic Server uses socket muxers, which are software modules, to read incoming requests on the server. Muxers read messages from the network, bundle them into a package of work and queue them to the Work Manager, which then finds a thread on which to execute the work and makes sure the response gets back to the same socket from which the request came. There are two types of muxers -- a Java muxer and a native muxer. A Java muxer uses pure Java to read data from the sockets, whereas the native muxers use platform-specific native binaries. By default, Oracle WebLogic Server uses the native muxer -- that is, the Enable Native IOP parameter for the server is set to the value SELECTED. Note that with a native muxer, the server creates a fixed number of threads to read incoming requests, whereas with a Java muxer you can configure the number of threads in the Administration Console by modifying the Percent Socket Readers parameter. The native muxer allocates a certain percentage of the server threads to act as socket reader threads, which perform the pooling function, while the rest of the server threads are busy processing client requests. In general, you need to be careful about changing the number of socket reader threads. In many cases, the best optimization is to set it to 1.

You can tell if you're using a native muxer or a Java muxer by looking at the messages that involve the execute thread. If you're using the native muxer, the server error messages will refer to it as weblogic.socket.EPollSocketMuxer, whereas if you're using the Java muxer you’ll see weblogic.socket.SocketMuxer instead. Note that the EPollSockerMuxer is associated only with a JRockit JVM operating on a Linux server. You’ll see the word poll in the case of a native muxer because it uses a polling mechanism to query a socket for data. Native muxers are seen as providing superior performance, especially when scaling to large user bases, because they implement a nonblocking thread model. When administering WebLogic Server instances, you'll frequently encounter the "stuck thread" situation, which occurs when a thread isn't returned to the thread pool within the time you set for it (the default is 10 minutes). Resolution of stuck threads is a key component of WebLogic Server troubleshooting, and you'll notice that Oracle Support often asks for several server thread dumps when you open a service request. Chapter 6 shows you how to take a thread dump and analyze many performance issues on your own by identifying the resource contention leading to the stuck thread situation.

Implementing the JMX API and MBeans

WebLogic Server implements the system administration infrastructure with Sun's Java Management Extensions (JMX). Implementing the JMX API involves using Java MBeans (managed beans) to model system administration tasks. If you understand MBeans and the JMX API, you can use them to create your own custom management tools. However, all administrative tools, such as the Administration Console, use the same MBeans and JMX API, so you don't have to reinvent the wheel by creating custom management tools. While a WebLogic Server administrator doesn't need to know how to program the JMX API, it helps to understand the different types of MBeans and how the JMX API interacts with them.

WebLogic Server uses two basic types of MBeans -- configuration MBeans and runtime MBeans -- to configure, monitor and manage the server and its resources.

• Configuration MBeans contain the configuration information for servers and resources that is stored in the domain's configuration files, such as the config.xml file and other XML files. These are persistent MBeans, and the domain's configuration file, config.xml, stores the attribute values for these MBeans. Whenever you change a configuration attribute using a system administration tool such as the Admin Server, those changes persist in the config.xml file. Configuration values can also be set by modifying the startup scripts and adding additional arguments via the -D option in the Java startup command. The config.xml file automatically gets updated when you change any configuration settings. When a Managed Server starts up, it contacts the Admin Server and gets a copy of the configuration information, which it stores in memory as configuration MBeans. Thus, all server instances in a domain have the same in-memory representation of the domain's configuration. Note that any attributes you change when starting a Managed Server won't affect the config.xml file, which is modified only if you change an attribute value on the Admin Server. When you shut down a server instance, all configuration MBeans hosted by that server are destroyed.
• Runtime MBeans help you monitor running server instances and contain attributes that hold run-time information for server instances and applications. Each of the server's resources updates the relevant run-time MBean following a change in its state. For example, the ServerRuntimeMBean is instantiated by the server when it starts up and contains the run-time data for the server. Runtime MBeans consist only of run-time data and nothing else, and when you shut down the server, the run-time statistics in the ServerRuntimeMBean are destroyed, as is the case with all the other runtime MBeans.

MBean Servers act as containers for the various MBeans, and the servers create and provide access to the MBeans. Oracle provides three types of MBean Servers. The Admin Server hosts an instance of the Domain Runtime MBean Server, which manages the MBeans for domain-wide services. Both Managed Servers and the Admin Server host an instance of the Runtime MBean Server, which lets you configure server instances. The Admin Server also hosts the Edit MBean Server, which manages pending configuration changes. The Admin and the Managed Servers also can optionally host the JVM's Platform MBean Server, which controls MBeans that contain monitoring information for the JDK.

You can change most domain configuration attributes dynamically while the server instances are running. In cases where dynamic configuration of an attribute isn't possible, you must restart the server instance. Run-time values of the attributes you configure will reflect your changes immediately, and the values are persisted in the config.xml file.

Development and Production Mode

By default, WebLogic Server domains run in the development mode using the Sun Java Development Kit (JDK). In this mode, auto-deployment of applications is enabled and the Admin Server creates a boot.properties file automatically when you start it up. You can also use the demo certificates for Secure Sockets Layer (SSL) without any warnings from WebLogic Server. The development mode is provided to get developers up and running quickly without having to worry about advanced deployment, configuration or security issues.

In the production mode, WebLogic Server defaults to using JRockit as the default JDK. In addition, you can't use the auto-deployment feature in production, and WebLogic Server issues warnings if you use the demo certificates for SSL. In the production mode, you're also prompted for usernames and password when you start up the instances.

It's easy to toggle between the development and production modes, and you learn how to do so in Chapter 2.

Listen Ports and Listen Threads

Listen ports listen for connection requests, and as connections come in the listen thread assigned by the server to the listen port accepts the connection requests, establishes connections and hands the requests over to the socket muxer.

By default, Oracle WebLogic Server uses two listen ports to listen to incoming requests for connections. The first listen port, which I'll call a normal listen port, will accept any type of request -- administrative as well as user requests. The normal listen port accepts connections from various protocols such as HTTP, t3, IIOP, COM, LDAP and SNMP. When you start up a WebLogic Server instance, it starts listening on two different ports. The first one is a normal plain-text port, and the second is a SSL listen port that also accepts requests for connections from clients over protocols such as HTTPS, t3s, IIOPS, COMS and LDAPS.

The second listen port is called an administration port. When you configure an administration port, the requests must use SSL, at which point you won't be able to direct any administrative requests to the normal port. Here's an informational message from the server when it starts up that shows the two default listen ports in action:

<Jan 30, 2011 12:12:01 PM EST> <Notice> <Server> <BEA-002613> <Channel "Default[7]" is now listening on fe80:0:0:0:e066:c24c:22cc:3d30:7001 for protocols iiop,t3, ldap, snmp, http.><Jan 30, 2011 12:12:01 PM EST> <Notice> <Server> <Channel "DefaultSecure[3]"is now listening on 192.168.1.2:7002 for protocols iiops, t3s, ldaps, https.>

While using the administration port is optional, note that you can start a server in the standby mode only if you use an administration port. In standby mode the normal port will be unavailable, so you must use the administration port to manage the server. In addition, having two separate ports -- one for administrative operations and the other for the application traffic -- prevents a conflict between these two types of network traffic. In a production environment, you can thus ensure that critical administrative operations, such as starting and stopping servers or deploying applications, don't compete with the application traffic. The administration port accepts only secure SSL traffic, so all connections through this port will have to be authenticated. Note that only administrative users can authenticate on the administration port, and no administrative traffic is rejected on nonadmin ports when you enable the administration port.

Choosing a JVM

In order to run Oracle WebLogic Server, you'll need a Java Virtual Machine (JVM). Oracle offers two types of JVMs for you when you install Oracle WebLogic Server -- the Sun Hotspot JVM and the Oracle JRockit JVM. Oracle recommends that you use the JRockit JVM for production installations because of the many benefits offered by it, including higher performance, increased scalability and better manageability when compared to the Sun JVM.

You configure the default JVM for a domain when creating a domain with the Configuration Wizard or with the WebLogic Scripting Tool (WLST). If you choose Production Mode on the Configure Server Start Mode and JDK page during the Configuration Wizard's domain creation process, the choice of the JVM will default to the JRockit SDK. If you select Development Mode, on the other hand, your domain will be configured to use the Sun SDK.

It's easy to change the JDK after you create the domain. Just set the JAVA_VENDOR environment variable in the startWebLogic.cmd script (or the startWebLogic.sh script in UNIX), as shown here:

• $ set JAVA_VENDOR=BEA /* For JRockit JVM
• $ set JAVA_VENDOR=sun /* for Sun JVM

In the latest release of WebLogic Server, you can also set the value of the JAVA_VENDOR variable to Oracle in order to specify the JRockit JVM. You can confirm the JVM version the server is using by viewing the command window output after you start a WebLogic Server instance. Be sure to check the JRockit documentation for vendor-specific options if you're new to this JVM. You can use JRockit to run any applications that were created with the Sun JDK.

Using Web Server Plug-Ins

While WebLogic Server comes with a built-in web server, you can also use a third-party web server, such as the Apache HTTP Server, for example. Web servers can be used to field requests for simple, static HTML content; but dynamic content, such as that delivered by Java web applications developed as JSPs or servlets, are hosted on the WebLogic Server and the web server routes requests for the dynamic content to WebLogic Server. The web server can use a WebLogic proxy plug-in or the WebLogic Server-provided servlet named HTTPClusterServlet to direct servlet and JSP requests to the cluster. You must configure HTTPClusterServlet as the default web application on the proxy server machine if you want to use this instead of a proxy plug-in.

You can install a WebLogic plug-in on the web server, allowing it to talk to the applications running on WebLogic Server. Your WebLogic Server installation comes with plug-ins for the following web servers:

• Apache HTTP Server
• Microsoft Internet Information Server
• Sun Java System Web Server

You can use a proxy plug-in to proxy requests from the web server to the clustered WebLogic Server instances to provide load-balancing and failover capabilities for those requests. You can configure the SSL protocol to secure data exchanged between the Apache HTTP Server Plug-In and WebLogic Server. Please refer to Oracle WebLogic Server documentation on WebLogic Server plug-ins for more details about the various available plug-ins.

Although you use WebLogic Server for its capabilities in hosting dynamic enterprise-level applications, you can also use it as a full-fledged web server capable of hosting high-volume web sites and server-static HTML files, servlets, and JSPs.