Understanding the Work Managers

Understanding Execute Queues and Work Managers

 

Execute Queues: The main purpose of having the Execute Queues is to handle the request internal and external related to weblogic server. Here, external requests could be the requests related to:-

1)      applications deployed inside the weblogic server

2)      redirection requests from weblogic server to the database, etc

Internal requests could be either the communication between the managed servers or between the managed server and admin server, etc.

These requests are mainly handled using the threads. Hence, we can conclude that the Execute Queues are mainly used for thread management. This management is achieved by using the using the different queues like weblogic.kernel.default, weblogic.admin. HTTP, weblogic.admin.RMI, etc.

Work Managers:  With the release of the new versions of weblogic server and new advancement the execute queues or the thread management in weblogic server also had the enhancements. From Weblogic Server 9x we had a replacement done to Execute Queues with the introduction of Work Managers.

With introduction of Work Managers, weblogic server helps to prioritize work and allocate the threads based on an execution model. The is taken care by the administrator-defined parameters after observing the actual run-time performance, throughput, monitoring, etc. Defining of this behaviour or rules is done at the different levels differently for differently for different applications, group of applications, etc as per the requirement. We can define one or more of the following Work Manager components in our deployment descriptor or config files:

1) Fair Share Request Class:

2) Response Time Request Class:

3) Min Threads Constraint:

4) Max Threads Constraint:

5) Capacity Constraint

6) Context Request Class

Work Managers can be configured either at the domain level, application level, module level in one of the following configuration files:

a) config.xml — Work Managers specified in config.xml can be assigned to any application, or application component, in the domain. You can use the Administration Console to define a Work Manager.

b) weblogic-application.xml — Work Managers specified at the application level can be assigned to that application, or any component of that application.

c) weblogic-ejb-jar.xml or weblogic.xml — Work Managers specified at the component-level can be assigned to that component.

d) weblogic.xml — Work Managers specified for a Web Application

The scope of the work managers could be any of the following three:

1) The default Work Manager

2) Global Work Managers

3) Application-scoped Work Managers

Default Work Manager: These are used to handle thread management and perform self-tuning.This Work Manager is used by an application when no other Work Managers are specified in the application’s deployment descriptors.

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. Applications are given equal priority for threads and are prevented from monopolizing them.

Global Work Managers: These have the scope of the domain. Global Work Managers are created in the WebLogic Administration Console using the following steps:

a) Login to WebLogic Admin Console and click on the left Panel “Work Manager”.

b) Then click on “Lock and Edit” button and click on “New” button from right panel

c) Select “Work Manager” radio button from Select Work Manager Definition type then click on Next.

d) Give the work Manager Name and click Next.

e) Now Target it to any Server or Cluster.

f) Now click on “Finish” and then “Activate Changes”

These are then defined in config.xml.

An application uses a globally defined Work Manager as a template. Each application creates its own instance which handles the work associated with that application and separates that work from other applications. This separation is used to handle traffic directed to two applications which are using the same dispatch policy. Handling each application’s work separately, allows an application to be shut down without affecting the thread management of another application. Although each application implments its own Work Manager instance, the underlying components are shared.

Application-scoped Work Managers: In addition to globally-scoped Work Managers, you can also create Work Managers that are available only to a specific application or module. Work Managers can be specified in the following descriptors:

a) weblogic-application.xml

b) weblogic-ejb-jar.xml

c) weblogic.xml

If you do not explicitly assign a Work Manager to an application, it uses the default Work Manager.

Although from weblogic server 9x execute queues are not available still you can enable Execute Queues (backward compatability) in the following ways:

1) Using the command line option: Dweblogic.Use81StyleExecuteQueues=true

2) Setting the Use81StyleExecuteQueues property via the Kernel MBean in config.xml

After enabling, Work Managers are converted to Execute Queues based on the following:

1) If the Work Manager implements a minimum or maximum threads constraint, then an Execute Queue is created with the same name as the Work Manager. The thread count of the Execute Queue is based on the value defined in the constraint.

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

For more information please refer to the link:

http://download.oracle.com/docs/cd/E11035_01/wls100/config_wls/self_tuned.html#wp1067159