Work Managers

In the previous versions of Weblogic, the processing of requests is done by multiple execute Queues. Different queues exist to work based on priority and requirements to avoid deadlocks. Weblogic also has some pre-configured Queues that work for the internal traffic like RMI calls etc.

The threads in execute Queue can be managed by the users. Weblogic also provides the ability for configuring custom execute Queue to make sure that certain applications has access to fixed number of threads to handle the load.

Weblogic Server uses a single thread pool, in which all types of work are executed. Weblogic Server prioritizes work based on rules you define, and run-time metrics, including the actual time it takes to execute a request and the rate at which requests are entering and leaving the pool.

From Weblogic Version 9.0, Work managers were introduced. Weblogic Server prioritizes work and allocates threads based on an execution model that consider administrator defined configuration parameters and also run time performance data.

Weblogic uses a single common thread pool for performing work. The size of the thread pool is determined by the kernel and will be resized when required. The Thread pool monitors the overall throughput every two seconds and uses the collected data to determine if thread count needs to change. The current thread pool count , the historical data related to the throughput and past history is taken in to consideration in determining whether the thread pool size needs to be increased or not.

Besides the thread pool, there is a priority Queue which is something like a regular Queue data structure where each element in it has a priority associated with that. In a priority queue, an element with high priority is served before an element with low priority. If two elements have the same priority, they are served according to their order in the queue. Now in Weblogic, the priority of the requests is calculated internally.

So at this point, we no longer have to configure thread counts on a work manager as it will take care of that. However it is possible to affect how server prioritizes work and allocates threads by parameters defined in Work Manager.

User can configure work manager and associate with an application or with a group of application components so that Weblogic server can work based on this configuration and assign pending work and enquired request to execution threads.

Work manager Components

The following are the work manager components that you can associate with the application,

• Request class
• Fair-share
• Response-time goal
• Context based
• Constraints
• Minimum threads constraint
• Maximum threads constraint
• Capacity

The request classes affect how requests are prioritized. Request classes help ensure that high priority work is scheduled before less important work, even if the high priority work is submitted after the lower priority work.

A Constraint defines minimum and maximum numbers of threads allocated to execute requests. It also defines the total number of requests that can be queued or executing before weblogic server begins rejecting requests. If the requests exceed or go down with the numbers defined in the constraints, the weblogic server either queues them or rejects them. When the requests are rejected, a HTTP response code of 503 is thrown back.

Work Manager Configuration

Work managers can be configured either in

Domain level -

Config.xml file is used to define global work managers which can be assigned to any application, application component etc

Application level -

Weblogic-application.xml file is used to define for application level which can be used to assign to that specific application or any component in that application

Component Level –

Weblogic-ejb-jar.xml or weblogic.xml files can be used to define work managers in the component level that can be assigned to the component.

Web application Level-

weblogic.xml file in web application are used to define work managers.

Work manager Scope

The scope of the work manager can be any one in the below list

The default Work Manager

This is the default work manager used when none were specified. This will be the default one that will be used by all applications. In many situations, the default Work Manager may be sufficient for most application requirements. Weblogic Server’s thread-handling algorithms assign each application its own fair share by default.

Global Work Managers

When we login to the weblogic console and create a Work manager we are actually creating a global work manager which will be defined in the config.xml file.

The global work manager is used by the application as a template. Each application running will create its own instance which handles the work associated with that application and separates the work from other applications. Handling each application’s work separately, allows an application to be shut down without affecting the thread management of another application. Although each application implements its own Work Manager instance, the underlying components are shared.

Application-scoped Work Managers

Though the default work manager and a global work manager are available but if you can also create Work Managers that are available only to a specific application or module you can configure them in Weblogic-application.xml, Weblogic-ejb-jar.xml or weblogic.xml and finally weblogic.xml file ( as defined in the Work manager configurations )

Does Execute Queue still exist?

As we said the work manager are implemented from Weblogic 9, we can even now configure Execute queues by using

• Using the command line option: Dweblogic.Use81StyleExecuteQueues=true
• Setting the Use81StyleExecuteQueues property via the Kernel MBean in config.xml

Once either of this is used to enable Execute Queue, work managers are converted to execute queue based on

• If the work manager has  minimum or maximum threads constraint, a execute queue is created with same name of work manager and thread count will the value defined in the constraint

• If the Work Manager does not implement any constraints, then the global default Execute Queue is used

How to Configure

Now let’s see how we can configure a Work manager and test it.

1. Open the admin console, click on the work Managers. In the next screen select the Work manager definition type and click next.

Give the name as “myTestWorkManager” and target it to a server.

Once this is saved. Click on the Created “myTestWorkManager” work Manager. Now we need to Configure the request class and Constraints as shown in the below image

Click on the request class - Select Context Request Class and in the next screen give it a name and deploy to the same target as above

Now click new after the Minimum Threads Constraint, in the next screen give a name and give count as 1 and in the next screen, select the target as same above

Now once again click the new after the Capacity Constraint, in the next screen, give a name and count to 1 and Select the target same as above

Once all the changes are done, we need to restart the servers for the changes to take place

You can see the names that I have used in the above screen.  So in the above work manager configuration we have defined the minimum thread constraint as “1” , this will make sure that only one thread will be executed at any point of time. When we start the application and try to access, we have already started a thread and when we try to access the same application again we will see a HTTP response code of 503.

Create Application

Now we have the work manager created and now we need configure this work manager to an application. For the demo purpose I created a sample war file which will run a jsp page which has code that will display 1 to 60 with 1000ms in gap.

Here is the code for the JSP page,

<%! static int counter=0; %>

<%

session.setAttribute("counter","Counter-"+counter);

counter++;

for(int id=0;id<60;id++)

  {

System.out.println(id+"\tRequest Is Being Processsed for  :"+(String)session.getAttribute("counter"));

try{

Thread.sleep(1000);

}

catch(Exception e)

{

e.printStackTrace();

}

}

out.println("<h2>Request Processing Completed");

%>

Now once we access the application, the first thread will run this code from 1 to 60 giving a gap of 1000ms. Once we try to access the same application again during the first thread still running we see a 503 error.

While creating the application we need to make sure the work manager is associated to the web application we created by adding the work manager details in the weblogic.xml file with

<weblogic-web-app>

<wl-dispatch-policy>myTestWorkManager</wl-dispatch-policy>

</weblogic-web-app>

I am attaching the war file for you testing purpose. Configure the work manager as above and deploy the code to the same server that the work manger was targeted and access the application using http://<IP address>:<Port>/myTestSample/index.jsp. The out put of the application can be seen in the command line. Here is the link for the application.

I will try to explain more about the work manager with more example. More to Come, Happy learning J