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.
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 threads – Default, 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:
- Open the Services window
- Right-click the Servers node and choose 'Add Server'
- Select Oracle WebLogic Server and click 'Next'
- 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.
- 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...
Alan Fryer shows you how to create a simple WebLogic Cluster on a virtual machine with two managed servers using Chef.
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.
Andrew Pielage focuses on WebLogic, specifically 12c, and configuring it to use Log4j and SLF4J with Logback.
In this post, Steve demonstrates how to write a simple websockets echo example using 12.1.2
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.
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.
Blogger Comment
Facebook Comment