The Overview:
Oracle WebLogic Server uses various types of threads to handle different tasks and operations within the server. Here are some of the most common types of threads used in Oracle WebLogic Server:
1. Execute Thread:
These threads are used to execute requests that are processed by WebLogic Server. They are responsible for executing application logic and handling incoming requests from clients.
2. Listen Thread:
These threads are used to listen for incoming requests on the server. They are responsible for accepting incoming connections from clients and passing them to the appropriate Execute Thread for processing.
3. Timer Thread:
These threads are used to execute scheduled tasks, such as periodic cleanup operations, database backups, and other maintenance tasks. They are responsible for executing tasks at specified intervals and can be configured to run on a specific schedule.
4. JDBC Connection Pool Thread:
These threads are used to manage connections to a database. They are responsible for acquiring, releasing, and monitoring database connections, and they help to ensure that database resources are used efficiently.
5. Work Manager Thread:
These threads are used to manage the processing of work requests. They are responsible for allocating work requests to appropriate threads based on specific criteria such as priority, availability, and other factors.
6. Problematic Threads:
In Oracle WebLogic Server, there are several types of problematic threads that can cause issues with server performance and availability:
(a) Stuck Threads:
Stuck threads are threads that are not making progress and are unable to complete their work. This can happen when a thread is blocked waiting for a resource that is unavailable, such as a database connection or a network resource. Stuck threads can cause performance issues, as they tie up system resources and prevent other threads from executing.
(b) Hogging Threads:
Hogging threads are threads that are using an excessive amount of CPU time, which can cause other threads to become unresponsive. This can happen when a thread is performing a long-running operation that consumes a large amount of CPU resources. Hogging threads can cause performance issues, as they prevent other threads from executing and can cause the system to become unresponsive.
(c) Leaked Threads:
Leaked threads are threads that are not properly released after they have completed their work. This can happen when a thread is not properly cleaned up after it finishes executing, which can cause the system to run out of resources over time. Leaked threads can cause performance issues, as they consume system resources and prevent other threads from executing.
(d) Deadlock Threads:
Deadlock threads are threads that are blocked waiting for each other to release resources that they both need. This can happen when multiple threads are trying to access shared resources in a conflicting manner. Deadlock threads can cause performance issues, as they tie up system resources and prevent other threads from executing.
(e) Hung Threads:
Hung threads are threads that are unresponsive and are not making progress. This can happen when a thread is blocked waiting for a resource that is never released or when a thread is caught in an infinite loop. Hung threads can cause performance issues, as they tie up system resources and prevent other threads from executing.
In the below snapshot, you can clearly see the Hogging, Standby and Stuck Threads section as highlight below. Go to the setting of the respective server. Click on the Monitoring tab then go to Threads section to get all the Thread Pool details as shown below:
7. Standby Threads:
In Oracle WebLogic Server, standby threads are a type of thread used in a cluster environment to improve performance and availability. When a server instance fails or is shut down for maintenance, its work is typically redistributed to other servers in the cluster. However, this redistribution can take some time, and during that time, the workload can become unbalanced, leading to performance issues. In above sample snapshot, you can easily identify the Standby Thread count as 10.
To address this issue, WebLogic Server uses standby threads, which are threads that are running but are not currently handling requests. Standby threads are available to handle requests in the event of a server failure or shutdown. When a server goes down, its standby threads are immediately available to handle requests, reducing the impact of the failure on the overall system.
Standby threads are typically configured as part of a thread pool. Administrators can configure the number of standby threads in the pool, as well as other properties such as the maximum and minimum number of threads. By adjusting these properties, administrators can ensure that there are enough standby threads available to handle requests in the event of a failure, while still maintaining efficient resource usage.
Monitoring Threads using WLST in Weblogic
Monitoring threads using WLST (WebLogic Scripting Tool) in WebLogic Server is a useful technique to help administrators maintain the health and performance of the server. Here’s an overview of how to monitor threads using WLST:
- Connect to the WebLogic Server: Use the
connect()method in WLST to connect to the WebLogic Server. You’ll need to provide the hostname, port number, and credentials to connect.
connect('username','password','t3://localhost:7001')
- Get the MBean for the server runtime: Once you’re connected to the server, you can use the
getMBean()method to get the MBean for the server runtime. This MBean provides information about the server’s state and performance, including information about threads.
serverRuntime = getMBean('/ServerRuntimes/server1')
- Get the thread pool MBean: Next, you can use the
getThreadPoolRuntime()method to get the MBean for the thread pool. This MBean provides information about the thread pool, including the number of threads, the number of active threads, and the number of stuck threads.
threadPoolRuntime = serverRuntime.getThreadPoolRuntime()
- Get information about threads: Once you have the thread pool MBean, you can use its methods to get information about the threads in the pool. For example, you can use the
getExecuteThreadTotalCount()method to get the total number of threads in the pool, or thegetExecuteThreadIdleCount()method to get the number of idle threads.
threadCount = threadPoolRuntime.getExecuteThreadTotalCount()
idleThreadCount = threadPoolRuntime.getExecuteThreadIdleCount()
- Monitor stuck threads: To monitor stuck threads, you can use the
getStuckThreadCount()method to get the number of stuck threads in the pool. You can also use thegetStuckThreadIds()method to get a list of the IDs of stuck threads.
stuckThreadCount = threadPoolRuntime.getStuckThreadCount()
stuckThreadIds = threadPoolRuntime.getStuckThreadIds()
By using above WLST commands, you can easily get information about thread pools, thread counts, stuck threads, and administrators can identify and troubleshoot issues before they impact the server’s performance.
What are the different States of Threads in Oracle WebLogic Server
In Oracle WebLogic Server, threads can exist in various states depending on their current status and activity. Here are the different states of threads in WebLogic Server:
- New: When a thread is created, it is in the New state. In this state, the thread has been instantiated but has not started running yet.
- Runnable: When a thread is ready to run, it is in the Runnable state. In this state, the thread is waiting for a processor to be allocated to it so that it can start executing.
- Running: When a thread is actively executing code, it is in the Running state. In this state, the thread is performing its designated task.
- Blocked: When a thread is waiting for a resource, such as a lock or a network connection, it is in the Blocked state. In this state, the thread is not executing any code and is waiting for the required resource to become available.
- Waiting: When a thread is waiting for a specific condition to be met, it is in the Waiting state. In this state, the thread is not executing any code and is waiting for a signal to indicate that the condition has been met.
- Timed Waiting: When a thread is waiting for a specific amount of time, it is in the Timed Waiting state. In this state, the thread is not executing any code and is waiting for a specific duration of time before resuming execution.
- Terminated: When a thread has completed its task and has exited, it is in the Terminated state. In this state, the thread is no longer executing and cannot be restarted.
In WebLogic Server, threads can move between these states as they perform their designated tasks. The server uses various thread management strategies to ensure that threads are efficiently utilized and that the server can handle varying levels of incoming requests.
Cheers!!!
