WebLogic Server, like any other java application server, provides resources so that your applications use them to provide services. Unfortunately none of these resources are unlimited and they must be managed carefully. One of these resources is threads which are pooled to provide better throughput and performance along with the fast response time and to avoid deadlocks. Threads are execution points that WebLogic Server delivers its power and execute work. Managing threads is very important because it may affect the overall performance of the entire system. In previous releases of WebLogic Server 9.0 we had multiple execute queues and user defined thread pools. There were different queues for different type of work which had fixed number of execute threads.  Tuning of this thread pools and finding the proper number of threads was time consuming which required many trials.

WebLogic Server 9.0 and the following releases use a single thread pool and a single priority-based execute queue. All type of work is executed in this single thread pool. Its size (thread count) is automatically decreased or increased (self-tuned). The new “self-tuning” system simplifies getting the proper number of threads and utilizing them.

Work manager allows your applications to run concurrently in multiple threads. Work manager is a mechanism that allows you to manage and utilize threads and create rules/guidelines to follow when assigning requests to threads. We can set a scheduling guideline or priority a request with a work manager and then associate this work manager with one or more applications. At run-time, WebLogic Server uses these guidelines to assign pending work/requests to execution threads. The position of a request in the execute queue is determined by its priority. There is a default work manager that is provided. The default work manager should be sufficient for most applications. However there can be cases you want to change this default configuration. Your application(s) may be providing services that need mixture of fast response time and long running processes like batch updates. However wrong configuration of work managers can lead a performance penalty while expecting improvement.

We can define/configure work managers at;

•    Domain Level: config.xml
•    Application Level: weblogic-application.xml
•    Component Level: weblogic-ejb-jar.xml or weblogic.xml
(For a specific web application use weblogic.xml)

We can use the following predefined rules/constraints to manage the work;

•    Fair Share Request Class: Specifies the average thread-use time required to process requests. The default is 50.
•    Response Time Request Class: Specifies a response time goal in milliseconds.
•    Context Request Class: Assigns request classes to requests based on context information.
•    Min Threads Constraint: Limits the number of concurrent threads executing requests.
•    Max Threads Constraint: Guarantees the number of threads the server will allocate to requests.
•    Capacity Constraint: Causes the server to reject requests only when it has reached its capacity.


Let’s create a work manager for our application for a long running work.
Go to WebLogic console and select Environment | Work Managers from the domain structure tree. Click New button and select Work manager and click next.

Enter the name for the work manager and click next. Then select the managed server instances(s) or clusters from available targets (the one that your long running application is deployed) and finish.

Click on MyWorkManager, and open the Configuration tab and check Ignore Stuck Threads and save. This will prevent WebLogic to tread long running processes (that is taking more than a specified time) as stuck and enable to finish the process.