C2B2 logo icon

Oracle WebLogic Work Managers - A Practical Overview

by Andy Overton

In this post, Andy Overton presents an insight into Oracle WebLogic Work Managers, going through the basics of what they are, how they are used, and providing deeper configuration and deployment advice. Using a test project, he examines the practical application of work managers, and looks at the control you can get over request handling and prioritisation.

 

 

 

How to configure and test WebLogic Work Managers

 

 

 

 

 

 

Overview

 

 

 

So, first of all, what are Work Managers?
 
Prior to WebLogic 9, Execute Queues were used to handle thread management. You created thread-pools to determine how workload was handled. Different types of work were executed in different queues based on priority and order requirements. The issue was that it is very difficult to determine the correct number of threads required to achieve the throughput your application requires and avoid deadlocks.
 
Work Managers are much simpler. All managers share a common thread pool and priority is determined by a priority-based queue. The thread pool size is dynamically adjusted in order to maximise throughput and avoid deadlocks. In order to differentiate and prioritise between different applications, you state objectives via constraints and request classes (e.g. fair share or response time). 
 
More on this later!
 


Why use Work Managers?

If you don’t set up your own Work Managers, the default will be used. This gives all of your applications the same priority and they are prevented from monopolising threads. Whilst this is often sufficient, it may be that you want to ensure that:
 
  • Certain applications have higher priority over others.
  • Certain applications return a response within a certain time.
  • Certain customers or users get a better quality of service.
  • A minimum thread constraint is set in order to avoid deadlock.

 


Types of Work Manager

  • Default – Used if no other Work Manager is configured. All applications are given an equal priority.
  • Global – Domain-scoped and are defined in config.xml. Applications use the global Work Manager as a blueprint and create their own instance. The work each application does can then be distinguished from other applications.
  • Application – Application-scoped and are applied only to a specific application. Specified in either weblogic-application.xml, weblogic-ejb-jar.xml, or weblogic.xml.
 


Constraints and Request Classes

A constraint defines the minimum and maximum number of threads allocated to execute requests and the total number of requests that can be queued or executing before the server begins rejecting requests. Constraints can be shared by several Work Managers.
 
Request classes define how requests are prioritised and how threads are allocated to requests. They can be used to ensure that high priority applications are scheduled before low priority ones, requests complete within a given response time or certain users are given priority over others. Each Work Manager may specify one request class.
 


Types of Constraint

  • Max threadsDefault, unlimited.
    The maximum number of threads that can concurrently execute requests. Can be set based on the availability of a resource the request depends on e.g. a connection pool.
  • Min threads – Default, zero.
    The minimum number of threads to allocate to requests. Useful for preventing deadlocks.
  • Capacity – Default, -1 (never reject requests).
    The capacity (including queued and executing) at which the server starts rejecting requests.
 


Types of Request Class

 
  • Fair Share – Defines the average thread-use time. Specified as a relative value, not a percentage.
  • Response Time – Defines the requested response time (in milliseconds).
  • Context – Allows you to specify request classes based on contextual information such as the user or user group.
 
 

Initial Setup

For this blog the following versions of software were used:
 
  • Ubuntu 14
  • JDK 1.8.0_73
  • WebLogic Server 12.2.1
  • JMeter 2.13
  • NetBeans 8.1
 
So, first of all, install WebLogic and set up a very basic domain (test_domain) with just an Admin server.


Register the server with IDE:
  1. Open the Services window
  2. Right-click the Servers node and choose 'Add Server'
  3. Select Oracle WebLogic Server and click 'Next'
  4. Click 'Browse' and locate the directory that contains the installation of the server, then Click 'Next'. The IDE will automatically identify the domain for the server instance.
  5. Type the username and password for the domain.

 

Creating the test project

Select New Project: Java EE - Enterprise Application
Name: WorkManagerTest
Server: Oracle WebLogic Server
Under WorkManagerTest-war, right click 'Web Pages' and select 'New JSP'.
File Name: test.jsp
 
 
Change the body to:

 

 

Work manager test OK

<% Thread.sleep(1000); // sleep for 1 second %>


Right click on WorkManagerTest-war, select 'Deploy' and then go to: http://localhost:7001/WorkManagerTest-war/test.jsp where you should see your page displayed.


Now create another application, this time called WorkManagerTest-2. This will be identical to test 1 but change the JSP code to: Name - test-2.jsp

 

 

Work manager test 2 OK

<% Thread.sleep(1000); // sleep for 1 second %>

Go to the WebLogic console: http://localhost:7001/console

Go to Deployments - click on WorkManagerTest-war, select Monitoring, Workload. Here you can see the work managers, constraints and request classes associated with your application. As we haven’t yet set anything up the app is currently using the default Work Manager.


Creating the JMeter test

Right click on Test Plan and select Add Threads (Users) > Thread Group

 

Name: Work Manager Test

 

Number of Threads (users): 10

Ramp-Up Period (in seconds): 10


This will call your application once per second for 10 seconds.

 

Right click on your new Thread Group and select: Add > Sampler > HTTP Request

 

 

Name: test.jsp

 

Server Name: localhost

Port: 7001

Path: WorkManagerTest-war/test.jsp

 

Right click on Test - 10 users

 

Add, Listener, View Results in Table

Add, Listener, View Results Tree

 

Create another HTTP request as follows:

 

Name: test-2.jsp

Server Name: localhost

Port: 7001

Path: WorkManagerTest-2-war/test-2.jsp

 

Right click on Test - 10 users

 

Add, Listener, View Results in Table

Add, Listener, View Results Tree

 

Save your test plan and then run it.

 

 

Click on results tree and table. With tree, you can view request and response data; obviously not very interesting in our case, but handy if you want to see what's being returned from an app. More useful is View Results in Table. This is very handy for quickly seeing response times. You should see that each of your JSPs/applications was called 10 times and each time it took just over a second to return a response.

 



 

Creating the work managers

In the WebLogic admin console:

 

 
  • Environment: Work Managers
  • New: Work Manager
  • Name: WorkManager1
  • Target: AdminServer

 

 

Create another the same but name it 'WorkManager2'
 

 

 

Using Fair Share request classes

 

In the WebLogic admin console

 

 
  • Environment: Work Managers
  • New: Fair Share Request Class
  • Name: FairShareReqClass-80
  • Fair Share: 80
  • Target: AdminServer

 

 

Create another with name FairShareReqClass-20, Fair Share 20

 

 

Now we need to associate the request classes with the Work Managers.

 

 
  • Select WorkManager1, under Request Class select FairShareReqClass-80 and save.
  • Select WorkManager2, under Request Class select FairShareReqClass-20 and save.

 

For the changes to take effect you will need to restart the server.

 

 

Alter web.xml in both of the applications. This can be found under WEB-INF.

 

 

WorkManagerTest-war

 

 

Add:

 
        Test1        test.jsp                                         wl-dispatch-policy            WorkManager1            

 

 

WorkManagerTest-2-war

 

 

    Test2    test-2.jsp                                 wl-dispatch-policy        WorkManager2    

 

 

 


Now, when you run the JMeter test again, you should see results similar to the following:

 

 

 

 

 

 

 

 

 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

What we are seeing is that test1.jsp is using the Work Manager with a Fair Share request class set to 80, whereas test2.jsp is using one set to 20.
 
There is an 80% (80/100) chance that the next free thread will perform work for jsp1. There is a 20% (20/100) chance it will next service jsp2.
 
As mentioned previously, the values used aren’t a percentage, although in our case they happen to add up to 100.
 
If you were to add another jsp, also using the Fair Share request class set to 20 the figures would be different: jsp1 would have a 66.6% chance (80/120), and jsp 2 and 3 would both have a 16.6% chance (20/120).
 

Using Response Time request classes

 

Next we will take a look at using response time request classes. There is no need to alter either JSP - we will just create new request classes and set our work managers to use those.

 

In the WebLogic console, go to Environment – Work Managers

 
  • Select New: Response Time Request Class
  • Name: ResponseTime-1second
  • Goal: 1000
  • Target: AdminServer
 
Create another but with the following values:
 
  • Name: ResponseTime-5seconds
  • Goal: 5000
  • Target: AdminServer
 
Finally, alter the two work managers:

Alter WorkManager1 to use the ResponseTime-1second response class and WorkManager2 to use the ResponseTime-5seconds response class.

Then restart the server.

 
Now, alter your JMeter test so that it loops forever.
 
Run it again and you should see that to begin with it takes a little while for the work managers to take effect. After a while, however you should see that the responses to both the apps start to even out and take around a second.
 

This is described in the Oracle documentation: “Response time goals are not applied to individual requests. Instead, WebLogic Server computes a tolerable waiting time for requests with that class by subtracting the observed average thread use time from the response time goal, and schedules requests so that the average wait for requests with the class is proportional to its tolerable waiting time.”

 

Context request classes

Context request classes are compound request classes that provide a mapping between the request context and a request class. This is based upon the current user or the current user’s group.

So it’s possible to specify different request classes for the same servlet invocation depending on the user or group associated with the invocation.

I won’t create one as a part of this blog as they simply utilise the other request class types.

 

Using constraints

Constraints define the minimum and maximum number of threads allocated to execute requests and the total number of requests that can be queued or executing before WebLogic Server begins rejecting requests.
 
As they can cause requests to be queued up or even worse, rejected, they should be used with caution. A typical use case of maximum threads constraint is to take a data source connection pool size as the max constraint. That way you don’t attempt to handle a request where a database connection is required but cannot be got.
 
There are 3 types of constraint:
 
  • Minimum threads
  • Maximum threads
  • Capacity

The minimum threads constraint ensures that the server will always allocate this number of threads,  the maximum threads constraint defines the maximum number of concurrent requests allowed, and the capacity constraint causes the server to reject requests when it has reached its capacity.

 
To see how this works in action, let’s create some constraints. 

Under Work Managers in the WebLogic console create the following, all targeted to the AdminServer:
 
New Max Threads Constraint:
 
  • Name - MaxThreadsConstraint-3
  • Count – 3

New Capacity Constraint:
 
  • Name - CapacityConstraint-10
  • Count 10
 
Next, create a new Work Manager called ConstraintWorkManager, add the two constraints to it and then restart WebLogic.
 

Now, alter the Test1 application and change the Work Manager in web.xml from WorkManager1 to ConstraintWorkManager. Also, alter the sleep time from 1 second to 5 and then re-deploy your application.

 
Next, create a new JMeter test with the following parameters:
 
  • Number of Threads (users) – 10
  • Ramp-Up Period – 0
 

Run this test and you should see results similar to the following:

 
 
 
 
 
 
 




 

So, what’s happening here?


(Remember, we set the maximum threads to 3). We send in 10 concurrent requests, and 3 of those begin to be processed immediately, whilst the others are put in a queue. So, we get the following:
 

At the start:

 
 
 
 
After 5 seconds:






 


After 10 seconds:



 

After 15 seconds:





 
 

Next, change the JMeter test. Raise the number of users to 13 and run the test again. This time you will see that 3 of the requests fail. This is due to the Capacity Constraint being set to 10. This means that only 10 requests can be either processing or queued and the others are rejected.

If you call the application from your browser whilst the test is running you will see that you receive a 503--Service Unavailable error (this can be replaced with your own error page).
 

Take care when setting up thread constraints - you don’t want to be limiting what your server can process without good reason and you certainly don’t want to be rejecting requests without very good reason.

Conclusion

Hopefully, this overview of WebLogic Work Managers has given you an insight into what they are used for and how you can go about setting them up.
 
WebLogic does a good job of request handling itself out of the box but sometimes you will find that you need more control over which applications should take priority or what should happen in times of heavy load. 

In that case, Work Managers can prove very useful, although as with all such things – make sure you are certain of what you are trying to achieve, then test, test some more and then test again!
 
Knowing how you want your server to run and being sure how it is running are two very different things. Ensure you test for all potential loads and understand what will happen in all cases.


 

More popular WebLogic posts from our technical blog...


Installing WebLogic with Chef
Alan Fryer shows you how to create a simple WebLogic Cluster on a virtual machine with two managed servers using Chef.
 
Basic clustering with WebLogic 12c and Apache Web Server
Mike Croft demonstrates WebLogic’s clustering capabilities and shows you how to utilise the WebLogic Apache plugin to use the Apache Web Server as a proxy to forward requests to the cluster.
 
 
Alternative Logging Frameworks for Application Servers: WebLogic
Andrew Pielage  focuses on WebLogic, specifically 12c, and configuring it to use Log4j and SLF4J with Logback.


WebLogic 12c Does WebSockets - Getting Started
In this post, Steve demonstrates how to write a simple websockets echo example using 12.1.2


Weblogic - Dynamic Clustering in practice
In this blog post Andy looks at setting up a dynamic cluster on 2 machines with 4 managed servers (2 on each). He then deploys an application to the cluster and shows how to expand the cluster.


Getting the most out of WLDF Part 1: What is the WLDF?
The WebLogic Diagnostic Framework (WLDF) is an often overlooked feature of WebLogic which can be very powerful when configured properly.In this blog series, Mike Crosft points out some of the low-hanging fruit so you can get to know enough of the basics that you’ll be able to make use of some of the features, while having enough of a knowledge of the framework to take things further yourself.