Detailed description of Oracle WebLogic Server service framework

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.

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 information about 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.