Using Work Managers to Optimize Scheduled Work

 

+

Search Tips   |   Advanced Search

 

WebLogic Server lets you configure how your application prioitizes the execution of its work. Based on rules you define and by monitoring actual run-time performance, WebLogic Server can optimize the performance of your application and maintain service-level agreements. You define the rules and constraints for your application by defining a Work Manger and applying it either globally to a WebLogic Server domain or to a specific application component.

  1. Understanding How WebLogic Server Uses Thread Pools
  2. Understanding Work Managers
  3. Work Manager Scope
  4. Using Work Managers, Request Classes, and Constraints
  5. Deployment Descriptor Examples
  6. Work Managers and Execute Queues
  7. Accessing Work Managers Using MBeans
  8. Using CommonJ With WebLogic Server

 

Understanding How WebLogic Server Uses Thread Pools

WebLogic 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 common thread pool changes its size automatically to maximize throughput. The queue monitors throughput over time and based on history, determines whether to adjust the thread count. For example, if historical throughput statistics indicate that a higher thread count increased throughput, WebLogic increases the thread count. Similarly, if statistics indicate that fewer threads did not reduce throughput, WebLogic decreases the thread count. This new strategy makes it easier for administrators to allocate processing resources and manage performance, avoiding the effort and complexity involved in configuring, monitoring, and tuning custom executes queues.

 

Understanding Work Managers

WebLogic Server prioritizes work and allocates threads based on an execution model that takes into account administrator-defined parameters and actual run-time performance and throughput.

Administrators can configure a set of scheduling guidelines and associate them with one or more applications, or with particular application components. For example, you can associate one set of scheduling guidelines for one application, and another set of guidelines for other applications. At run time, WebLogic Server uses these guidelines to assign pending work and enqueued requests to execution threads.

To manage work in your applications, you define one or more of the following Work Manager components:

See also:

You can use any of these Work Manager components to control the performance of your application by referencing the name of the component in the application's deployment descriptor. In addition, you may define a Work Manager that encapsulates all of the above components (except Context Request Class; See Context Request Class) and reference the name of the Work Manager in your application's deployment descriptor. You can define multiple Work Managers—the appropriate number depends on how many distinct demand profiles exist across the applications you host on WebLogic Server.

You can configure Work Managers at the domain level, application level, and module level in one of the following configuration files, or by using the WebLogic Administration Console:

Listing 2-1 is an example of a Work Manager definition. Listing 2-1 Work Manager Stanza 

<work-manager>

<name>highpriority_workmanager</name>

   <fair-share-request-class>

      <name>high_priority</name> 

      <fair-share>100</fair-share> 

   </fair-share-request-class>

   <min-threads-constraint>

      <name>MinThreadsCountFive</name>

      <count>5</count>

   </min-threads-constraint>

</work-manager>

To reference the Work Manager in Listing 2-1 in the dispatch policy of a Web application, add the code in Listing 2-2 to the Web application's web.xml file: Listing 2-2 Referencing the Work Manager in a Web Application 

<init-param>

   <param-name>wl-dispatch-policy</param-name>

   <param-value>highpriority_workmanager</param-value>

</init-param>

The components you can define and use in a Work Manager are described in following sections:

 

Request Classes

A request class expresses a scheduling guideline that WebLogic Server uses to allocate threads to requests. 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. WebLogic Server takes into account how long it takes for requests to each module to complete.

There are multiple types of request classes, each of which expresses a scheduling guideline in different terms. A Work Manager may specify only one request class.

The value of a fair share request class is specified as a relative value, not a percentage. Therefore, in the above example, if the request classes were defined as 400 and 100, they would still have the same relative values.

 

Context Request Class

A context request class lets you define request classes in an application's deployment descriptor based on a user's context. For example: Listing 2-3 Context Request Class 

<work-manager>

  <name>responsetime_workmanager</name>

    <response-time-request-class>

      <name>my_response_time</name>

      <goal-ms>2000</goal-ms>

   </response-time-request-class>

</work-manager>



<work-manager>

  <name>context_workmanager</name>

  <context-request-class>

    <name>test_context</name>

    <context-case>

      <user-name>system</user-name>

      <request-class-name>high_fairshare</request-class-name> 

   </context-case>

   <context-case>

      <group-name>everyone</group-name>

      <request-class-name>low_fairshare</request-class-name> 

    </context-case>

  </context-request-class>

</work-manager>

If a Web application's Work Manager references a context request class, the first user call will go through the default request class; subsequent calls in same session will go through the user-defined request class.

The previous sections described request classes based on fair share and response time by relating the scheduling to other work using the same request class. A mix of fair share and response time request classes is scheduled with a marked bias in favor of response time scheduling.

 

Constraints

A constraint defines minimum and maximum numbers of threads allocated to execute requests and the total number of requests that can be queued or executing before WebLogic Server begins rejecting requests.

You can define the following types of constraints:

 

Stuck Thread Handling

In response to stuck threads, you can define a Stuck Thread Work Manager component that can shut down the Work Manager, move the application into admin mode, or mark the server instance as failed.

For example, the Work Manager defined in Listing 2-4 shuts down the Work Manager when two threads are stuck for longer than 30 seconds. Listing 2-4 Stuck-Thread Work Manager

<work-manager>
<name>stuckthread_workmanager</name>
<work-manager-shutdown-trigger>
<max-stuck-thread-time>30</max-stuck-thread-time>
<stuck-thread-count>2</stuck-thread-count>
</work-manager-shutdown-trigger>
</work-manager>

 

Work Manager Scope

Essentially, there are three types of Work Managers, each one characterized by its scope and how it is defined and used.

 

The Default Work Manager

To handle thread management and perform self-tuning, WebLogic Server implements a default Work Manager. 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.

Overriding the Default Work Manager

You can override the behavior of the default Work Manager by creating and configuring a global Work Manager called default. This allows you to control the default thread-handling behavior of WebLogic Server.

When you override the default Work Manager, all instances are overridden.

When to Use Work Managers

Use the following are guidelines to help you determine when you might want to use Work Managers to customize thread management:

 

Global Work Managers

You can create global Work Managers that are available to all applications and modules deployed on a server, in the WebLogic Administration Console and 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 implements 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. You can define application-scoped Work Managers in the WebLogic Administration Console and in the following descriptors:

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

A method is assigned to a Work Manager, using the <dispatch-policy> element in the deployment descriptor. The <dispatch-policy> can also identify a custom execute queue, for backward compatibility. For an example, see Listing 2-2.

 

Using Work Managers, Request Classes, and Constraints

Work Managers, Request Classes, and Constraints require the following:

 

Dispatch Policy for EJB

weblogic-ejb-jar.xml—The value of the existing dispatch-policy tag under weblogic-enterprise-bean can be a named dispatch-policy. For backwards compatibility, it can also name an ExecuteQueue. In addition, we allow dispatch-policy, max-threads, and min-threads, to specify named (or unnamed with numeric value for constraints) policy and constraints for a list of methods, analogously to the present isolation-level tag.

 

Dispatch Policy for Web Applications

weblogic.xml—Also supports mappings analogous to the filter-mapping of the web.xml, where named dispatch-policy, max-threads, or min-threads are mapped for url-patterns or servlet names.

 

Deployment Descriptor Examples

This section contains examples for defining Work Managers in various types of deployment descriptors.

For additional reference, see the schema for these deployment descriptors:

These EJBs are configured to get as many threads as there are instances of a resource they depend upon—a connection pool, and an application-scoped connection pool. 

</weblogic-ejb-jar>

<weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90"

   xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"

   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

   xsi:schemaLocation="http://www.bea.com/ns/weblogic/90

   http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">



   <weblogic-enterprise-bean>

     <ejb-name>ResourceConstraintEJB</ejb-name> 

      <jndi-name>core_work_ejb_resource_ResourceConstraintEJB</jndi-name> 

      <dispatch-policy>test_resource</dispatch-policy> 

   </weblogic-enterprise-bean>



   <weblogic-enterprise-bean>

      <ejb-name>AppScopedResourceConstraintEJB</ejb-name> 

      <jndi-name>core_work_ejb_resource_AppScopedResourceConstraintEJB

      </jndi-name>

      <dispatch-policy>test_appscoped_resource</dispatch-policy> 

   </weblogic-enterprise-bean>



<work-manager>

   <name>test_resource</name>

    <max-threads-constraint>

      <name>pool_constraint</name>

      <pool-name>testPool</pool-name>

   </max-threads-constraint>

</work-manager>



<work-manager>

   <name>test_appscoped_resource</name>

   <max-threads-constraint>

      <name>appscoped_pool_constraint</name>

      <pool-name>AppScopedDataSource</pool-name>

   </max-threads-constraint>

</work-manager>

</weblogic-ejb-jar>
Listing 2-7 weblogic-ejb-jar.xml with commonJ Work Managers

For information using commonJ, see Using CommonJ With WebLogic Server and the commonJ Javadocs. Listing 2-8 weblogic-application.xml 

<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90"

   xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"

   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

   xsi:schemaLocation="http://www.bea.com/ns/weblogic/90

   http://www.bea.com/ns/weblogic/90/weblogic-application.xsd">



   <max-threads-constraint>

      <name>j2ee_maxthreads</name> 

      <count>1</count> 

   </max-threads-constraint>



   <min-threads-constraint>

      <name>j2ee_minthreads</name> 

      count>1</count> 

   </min-threads-constraint>



   <work-manager>

      <name>J2EEScopedWorkManager</name> 

      </work-manager>

</weblogic-application>
Listing 2-9 Web Application Descriptor

This Web application is deployed as part of the Enterprise application defined in Listing 2-8. This Web application's descriptor defines two Work Managers. Both Work Managers point to the same max threads constraint, j2ee_maxthreads, which is defined in the application's weblogic-application.xml file. Each Work Manager specifies a different response time request class. 

<weblogic xmlns="http://www.bea.com/ns/weblogic/90"

   xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"

   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

   xsi:schemaLocation="http://www.bea.com/ns/weblogic/90

   http://www.bea.com/ns/weblogic/90/weblogic.xsd">



   <work-manager>

      <name>fast_response_time</name> 

      <response-time-request-class>

         <name>fast_response_time</name> 

         <goal-ms>2000</goal-ms> 

      </response-time-request-class>

      <max-threads-constraint-name>j2ee_maxthreads

      </max-threads-constraint-name>

   </work-manager>



   <work-manager>

      <name>slow_response_time</name> 

      <max-threads-constraint-name>j2ee_maxthreads

      </max-threads-constraint-name

      <response-time-request-class>

         <name>slow_response_time</name> 

         <goal-ms>5000</goal-ms> 

      </response-time-request-class>

   </work-manager>



</weblogic>
Listing 2-10 Web Application Descriptor

This descriptor defines a Work Manager using the context-request-class. 

<?xml version="1.0" encoding="UTF-8"?>

<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90"

xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.bea.com/ns/weblogic/90

http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd">

 <work-manager>

  <name>foo-servlet-1</name>

  <request-class-name>test-fairshare2</request-class-name>

  <max-threads-constraint>

    <name>foo-mtc</name>

    <pool-name>oraclePool</pool-name>

  </max-threads-constraint>

 </work-manager>



 <work-manager>

  <name>foo-servlet</name>

  <context-request-class>

  <name>test-context</name>

  <context-case>

    <user-name>anonymous</user-name>

    <request-class-name>test-fairshare1</request-class-name> 

  </context-case>

   <context-case>

    <group-name>everyone</group-name>

    <request-class-name>test-fairshare2</request-class-name> 

   </context-case>

  </context-request-class>

 </work-manager>

</weblogic-web-app>

 

Work Managers and Execute Queues

This section describes how to enable backward compatibility with Execute Queues and how to migrate applications from using Execute Queues to Work Managers.

 

Enabling Execute Queues

WebLogic Server, Version 8.1, implemented Execute Queues to handle thread management in which you created thread-pools to determine how workload was handled. WebLogic Server still provides Execute Queues for backward compatibility, primarily to facilitate application migration. However, when developing new applications, you should use Work Managers to perform thread management more efficiently.

You can enable Execute Queues in the following ways:

Enabling Execute Queues disables all Work Manager configuration and thread self tuning. Execute Queues behave exactly as they did in WebLogic Server 8.1. See Using User-Defined Execute Queues in WebLogic Server Performance and Tuning.

When enabled, Work Managers are converted to Execute Queues based on the following rules:

 

Migrating from Execute Queues to Work Managers

When an application is migrated from WebLogic Server 8.1, any Execute Queues defined in the server configuration before migration will still be present. WebLogic Server does not automatically convert the Execute Queues to Work Managers.

When an 8.1 application implementing Execute Queues is deployed on WebLogic Server 9.x, the Execute Queues are created to handle thread management for requests. However, only those requests whose dispatch-policy maps to an Execute Queue will take advantage of this feature.

 

Accessing Work Managers Using MBeans

Work Managers can be accessed using the WorkManagerMBean configuration MBean. For more information, see WorkManagerMBean.

WorkManagerMBean is accessed in the runtime tree or configuration tree depending on how the Work Manager is accessed by an application.

 

Using CommonJ With WebLogic Server

WebLogic Server Work Managers provide server-level configuration that allows administrators a way to set dispatch-policies to their servlets and EJBs.

WebLogic Server also provides a programmatic way of handling work from within an application. This is provided via the CommonJ API. Weblogic Server implements the commonj.work and commonj.timers packages of the CommonJ specification.

For specific information on WebLogic Server's implementation of CommonJ, see the CommonJ Javadocs.

The WebLogic Server implementation of CommonJ enables an application to break a single request task into multiple work items, and assign those work items to execute concurrently using multiple Work Managers configured in WebLogic Server. Applications that do not need to execute concurrent work items can also use configured Work Managers by referencing or creating Work Managers in their deployment descriptors or, for Java EE Connectors, using the JCA API.

The following are some differences between the WebLogic Server implementation and the CommonJ specification:

 

Accessing CommonJ Work Managers

Unlike WebLogic Server Work Managers, which can only be accessed from an application via dispatch policies, you can access CommonJ Work Managers directly from an application. The following code example demonstrates how to lookup a CommonJ Work Manager using JNDI: 

InitialContext ic = new InitialContext();

commonj.work.WorkManager wm = 

(commonj.work.WorkManager)ic.lookup("java:comp/env/wm/myWM");

For more information on using CommonJ Work Managers, see the CommonJ Javadocs.

 

Mapping CommonJ to WebLogic Server Work Managers

You can map an externally defined CommonJ Work Manager to a WebLogic Server Work Manager. For example, if you have a CommonJ Work Manager defined in a descriptor, ejb-jar.xml, for example, as: 

<resource-ref>

<res-ref-name>minthreads_workmanager</res-ref-name>

<res-type>commonj.work.WorkManager</res-type>

<res-auth>Container</res-auth>

<res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

You can link this to a WebLogic Server Work Manager by ensuring that the name element is identical in the WebLogic Server descriptor such as weblogic-ejb-jar.xml: 

<work-manager>

<name>minthreads_workmanager</name>

<min-threads-constraint>

<count>5</count>

</min-threads-constraint>

</work-manager>

This procedure is similar for a resource-ref defined in web.xml. The WebLogic Server Work Manager can be defined in either a module descriptor (weblogic-ejb-jar.xml or weblogic.xml, for example) or in the application descriptor (weblogic-application.xml).