Understand the key concepts of the OracleWebLogic Server

In order to fully understand how the WebLogic Server works and to show it the best performance, we need to understand several concepts. The most important concepts are discussed in the following content. This article is the first part. This section briefly describes the internal architecture of the OracleWebLogic server.

In order to fully understand how the WebLogic Server works and to show it the best performance, we need to understand several concepts. The most important concepts are discussed in the following content. This article is the first part. This section briefly describes the internal architecture of the Oracle WebLogic Server.

In order to fully understand how the WebLogic Server works and to show it the best performance, we need to understand several concepts. The most important concepts are discussed in the following content. This article is the first part.

Execution thread and queue

This section briefly describes the internal architecture of the Oracle WebLogic Server. You can learn how the server performs work to meet user requests. When a client initiates a request to WebLogic, the actual response to the request is executed by a Java thread called the execution thread. You can use HTTP-based requests pointing to the Servlet engine or remote method calls (RMI) to access objects such as enterprise-level JavaBean (EJB) to submit work. When a server process starts, it binds itself to a port and assigns a listening thread for incoming requests to the port. Once the request establishes a connection, the server passes the control of the connection to the socket muxer. The Socket muxer reads the request from the socket and puts the work request into the self-adjusting execution queue when the request arrives. An idle execution thread will retrieve requests from the execution queue and forward the response of these requests to a dedicated processing thread. The execution thread executes the request and returns a response.

The Oracle WebLogic Server uses socket muxer (software module) to read incoming requests from the server. Muxer reads messages from the network, compress them into a work package, puts them into the work manager queue, executes the work through a thread, and ensures that the response is returned to the same socket of the request source. There are two types of muxer: Java Muxer and local muxer. Java muxer uses a dedicated platform's Local Binary Package. By default, Oracle WebLogic uses local muxer -- that is, the "enable local IOP" parameter of the server is selected. Note that if you use a local muxer, the server creates a fixed number of threads to read incoming requests, you can modify the "Socket reader percentage" parameter on the console to configure the number of threads. The local muxer allocates a specific proportion of server threads to serve as the socket reader thread to form a thread pool function, while the remaining server threads are busy processing client requests. In general, you need to be careful to modify the number of socket reader threads. In many cases, the optimal configuration is set to "1 ".

If you want to know whether the local muxer or Java muxer is used, check the execution thread involved in the message. If you are using a local muxer, the server error message will prompt "weblogic. socket. EPollSocketMuxer ". If you are using Java muxer, what you see will be" weblogic. socket. socketMuxer ". Note that "EPollSockerMuxer" is only related to JRockit JVM running on Linux servers. If it is configured as a local muxer, you can also see the "poll" text, because it uses a polling mechanism to query socket data. Local muxer is considered to provide better performance, especially when extended to a large user group because they use a non-blocking thread model. When managing WebLogic Server instances, you will often encounter "blocking Threads". This usually happens when a thread cannot be set for 10 minutes) it occurs when the thread pool is returned.

Run jmx api and MBeans

WebLogic Server is a Deployment System Management Infrastructure implemented by Java Management extension of Sum. Executing the jmx api involves using Java MBeans (managed bean) to model system management tasks. If you understand MBean and JMX APIs, you can use them to create your own management tools. However, all management tools (such as the Management Console) use the same MBean and JMX APIs, so you do not have to re-invent the wheel to create custom management tools. Although the WebLogic Server administrator does not need to know how to program using the jmx api, it helps to understand different types of mbeans and how JMX APIs interact with them if you have some knowledge about the programming.

WebLogic servers use two basic types of mbeans-configure mbeans and run mbeans-to configure, monitor, and manage servers and their resources.
Configuration MBean contains configuration information about servers and resources and is stored in the domain configuration file, such as the "config. xml" file or other XML files. These are persistent mbeans, and the domain configuration file (config. xml) Stores attribute values for these mbeans. No matter when you use a management tool (such as a management server) to modify the configuration attributes, these changes will be persistently stored in the "config. xml" file. By modifying the startup script, you can add the "-D" option to the Java startup command and modify the configuration value. If you modify any configuration settings, the "config. xml" file is automatically updated. When the managed server is started, it will contact the Management Server to obtain a copy of configuration information and store it as the configuration MBean in the memory. Therefore, all servers in the domain have the same configuration copy in the memory. Note that when you start a managed server, any attributes you modify will not affect "config. xml file; only the attribute values modified on the management server will be saved to "config. xml file. When you close a server instance, all configuration mbeans managed by the server will be destroyed.
MBean helps monitor running server instances. It includes attributes that keep the information of running server instances and applications. The resources of each server update related runtime mbeans, including their status changes. For example, "ServerRuntimeMBean" is initialized when the server is started, including the running data of the server. MBean only consists of runtime data and has no other content. When you shut down the server, runtime statistics in "ServerRuntimeMBean" are all destroyed, and other runtime mbeans are similar.

The MBean server acts as a variety of MBean containers. This server creates and provides access to MBean. Oracle provides three types of MBean servers. Manage the MBean server instance when the server is hosting the domain. It manages mbeans for services in the domain. Both the managed server and the managed server host the runtime MBean server, which allows you to configure Server instances. The management server also hosts the editing MBean server, which manages pending configuration changes. The Management Server and managed server can also host the MBean server of the JVM platform. It controls mbeans that contain JDK monitoring information.

You can dynamically modify most domain configuration attributes when the server instance is running. For attributes that do not support dynamic configuration, you must restart the server instance. The runtime attribute values you configured will immediately reflect your changes. These values will be permanently stored in the "config. xml" file.

Development Mode and product Mode

By default, the WebLogic Server domain runs in development mode and uses the Java Development Kit (JDK) of Sum ). In this mode, automatic application deployment is enabled, and the Management Server automatically creates the "boot. properties" file at startup. You can also use demo authentication for Secure Sockets Layer (SSL) without any warning on the WebLogic Server. The development mode is provided for developers to run quickly without worrying about advanced deployment, configuration, and security issues.

In product mode, the WebLogic server uses JRockit as the default JDK by default. In product mode, you cannot use the automatic deployment function. If you use demo version authentication for SSL, the WebLogic Server will issue a warning. In production mode, you are prompted to enter the user name and password when starting the instance.

Listening port and listening thread

The listening port is used to listen for connection requests. When connected, the server assigns the listening thread to the listening port to accept the connection request, establishes a connection, and passes the request to the socket muxer.

By default, the Oracle WebLogic Server uses two listening ports to listen for incoming connection requests. The first listening port is called a standard listening port, which accepts any type of requests, whether it is a management request or a user request. Standard listening ports accept connections from various protocols, such as HTTP, t3, IIOP, COM, LDAP, and SNMP. When you start the WebLogic server instance, it starts listening to two different ports. The first is the standard plain text port, and the second is the SSL listening port. The second listening port also accepts client connection requests such as HTTPS, t3s, IIOPS, COMS, and LDAPS.

The second listening port is called a Management port. When configuring the Management port, your request must use SSL. You cannot direct any management requests to the standard port. The following is a prompt message showing the behavior of two default listening ports when the server is started:




Although the Management port is optional, you must note that you can start the server in standby mode only when using the Management port. In standby mode, the standard port is unavailable, so you must use the Management port to manage the server. In addition, there are two independent ports, one for managing behavior operations and the other for application traffic, to avoid network traffic conflicts between the two types. Therefore, in a production environment, you can ensure that key management behaviors (such as starting and stopping servers and deploying applications) do not compete with applications. The Management port only accepts secure SSL communication. Therefore, all connections through this port must be authenticated. Note that only the management user can authenticate the Management port. If you enable the Management port, no management communication is denied on the non-Management port.

Select JVM

To run the Oracle WebLogic Server, you need a Java Virtual Machine (JVM ). When you install the Oracle WebLogic Server, Oracle provides two types of JVM for you to choose from: Sum Hotspot JVM and Oracle JRockit JVM. Oracle recommends that you use JRockit JVM in the production environment. Compared with Sum JVM, JRockit provides many benefits, including better performance and better scalability and management functions.

When using the Configuration Wizard or WebLogic script tool (WLST) to create a domain, you can configure JVM for the domain. In the domain creation process of the Configuration Wizard, if you select the product mode in the configuration server startup mode, the default JVM on the JDK page is JRockit SDK. If you select the development mode, the default configuration of your domain is Sun JDK.

It is also easy to modify the JDK configuration after the domain is created. You only need to set the "JAVA_VENDOR" environment variable in the "startWebLogic. cmd" script (or startWebLogic. sh script), as shown in the following script:
$ Set JAVA_VENDOR = BEA/* For JRockit JVM
$ Set JAVA_VENDOR = sun/* for Sun JVM



In the latest WebLogic Server, you can also set the "JAVA_VENDOR" variable value for Oracle to specify JRockit JVM. After starting the WebLogic server instance, you can check the output information in the Command window to confirm the JVM version of the server. If you are not familiar with JRockit JVM, take a look at this JVM document and there are some vendor-specific options. You can use JRockit to run any applications created with Sun JDK.

Use Web Server plug-in

Although WebLogic servers have built-in web servers, you can also use third-party web servers, such as Apache HTTP servers. Web servers can be used for simple external requests and static text pages. However, dynamic content, such as content submitted by Java Web applications developed by JSP or Servlet, is managed by the WebLogic Server, the web server only forwards these requests to the WebLogic Server. The Web server can use the WebLogic proxy plug-in or the servlet "HTTPClusterServlet" provided by the WebLogic Server to forward servlet and JSP requests to the cluster. If you want to use "HTTPClusterServlet" instead of the proxy plug-in, you must configure it as the default web application of the proxy server computer.

You can install the WebLogic Plugin on the web server, which allows the server to communicate with applications running on the WebLogic Server. The built-in plug-ins installed on the WebLogic server support the following Web servers:
Apache HTTP Server
Microsoft IIS server
Sun Java System Web Server

You can use the proxy plug-in to proxy requests from web servers and forward them to the WebLogic server instance of the cluster to provide load balancing and Failover functions for those requests. You can configure the SSL protocol to implement secure data exchange between the Apache HTTP Server plug-in and the WebLogic Server.

WebLogic servers can host dynamic enterprise-level applications as well as complete web servers to host static HTML files for high-capacity websites and servers, as well as servlet and JSP files.