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.
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
