Work Managers in Weblogic

 

Using Work Managers to Optimize Scheduled Work

WebLogic Server allows you to configure how your application prioritizes the execution of its work. Based on rules you define and by monitoring actual runtime 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 Manager and applying it either globally to the WebLogic Server domain or to a specific application component.

• Understanding How WebLogic Server Uses Thread Pools
• Understanding Work Managers
• Work Manager Scope
• Using Work Managers, Request Classes, and Constraints
• Deployment Descriptor Examples
• Work Managers and Execute Queues
• Accessing Work Managers Using MBeans

Understanding How WebLogic Server Uses Thread Pools

• In previous versions of WebLogic Server, processing was performed in multiple execute queues. Different classes of work were executed in different queues, based on priority and order requirements, and to avoid deadlocks. In addition to the default execute queue, weblogic.kernel.default, there were pre-configured queues dedicated to internal administrative traffic, such as weblogic.admin.HTTP and weblogic.admin.RMI.
• Users could control thread usage by altering the number of threads in the default queue or configure custom execute queues to ensure that particular applications had access to a fixed number of executing threads, regardless of overall system 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.
• 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 execute 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:

• Fair Share Request Class:
• Response Time Request Class:
• Min Threads Constraint:
• Max Threads Constraint:
• Capacity Constraint
• Context Request Class:

You can use any of these 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) 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.

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

• 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.
• Weblogic-application.xml—Work Managers specified at the application level can be assigned to that application or any component of that application.
• Weblogic-ejb-jar.xml or weblogic.xml—Work Managers specified at the component-level can be assigned to that component.
• XML—Work Managers specified for a Web Application.

Example of a Work Manager definition.

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

</work-manager>

To reference the Work Manager used in the example the dispatch policy of a Web Application, add the code in 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>

Work Manager Components:

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 class, each of which expresses a scheduling guideline in different terms. A Work Manager may specify only one request class.

• Fair-share-request-class—specifies the average thread-use time required to process requests.

For example, assume that WebLogic Server is running two modules. The Work Manager for ModuleA specifies a fair-share-request-class of 80 and the Work Manager for ModuleB specifies a fair-share-request-class of 20.

During a period of sufficient demand, with a steady stream of requests for each module such that the number of requests exceeds the number of threads, WebLogic Server will allocate 80% and 20% of the thread-usage time to ModuleA and modules, respectively.

Note:

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.

• response-time-request-class—This type of request class specifies a response time goal in milliseconds. 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 request so that the average wait for requests with the class is proportional to its tolerable waiting time.

For example, given that ModuleA and ModuleB in the previous example, have response time goals of 2000 ms and 5000 ms, respectively, and the actual thread use time for an individual request is less than its response time goal. During a period of sufficient demand, with a steady stream of requests for each module such that the number of requests exceeds the number of threads, and no “think time” delays between response and request, WebLogic Server will schedule requests for ModuleA and ModuleB to keep the average response time in the ratio 2:5. The actual average response times for ModuleA and ModuleB might be higher or lower than the response time goals, but will be a common fraction or multiple of the stated goal. For example, if the average response time for ModuleA requests is 1,000 ms., the average response time for ModuleB requests is 2,500 ms.

• context-request-class—This type of request class assigns request classes to requests based on context information, such as the current user or the current user’s group.

For example, the context-request-class in Context Request Class assigns a request class to requests based on the value of the request’s subject and role properties.

Context Request Class

A context request class allows you to 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>

Above, we explained the 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 schedule.

Constraints

A constraint defines the 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:

max-threads-constraint—This constraint limits the number of concurrent threads executing requests from the constrained work set. The default is unlimited. For example, consider a constraint defined with maximum threads of 10 and shared by 3 entry points. The scheduling logic ensures that not more than 10 threads are executing requests from the three entry points combined. A max-threads-constraint can be defined in terms of the availability of resources that requests depend upon, such as a connection pool. A max-threads-constraint might, but does not necessarily, prevent a request class from taking its fair share of threads or meeting its response time goal. Once the constraint is reached the server does not schedule requests of this type until the number of concurrent executions falls below the limit. The server then schedules work based on the fair share or response time goal.

min-threads-constraint—This constraint guarantees a number of threads the server will allocate to affected requests to avoid deadlocks. The default is zero. A min-threads-constraint value of one is useful, for example, for a replication update request, which is called synchronously from a peer. A min-threads-constraint might not necessarily increase a fair share. This type of constraint has an effect primarily when the server instance is close to a deadlock condition. In that case, the constraint will cause WebLogic Server to schedule a request even if requests in the service class have more requests than its fair share recently.

capacity—This constraint causes the server to reject requests only when it has reached its capacity. The default is -1. Note that the capacity includes all requests, queued or executing, from the constrained work set. Work is rejected either when an individual capacity threshold is exceeded or if the global capacity is exceeded. This constraint is independent of the global queue threshold.

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 instance, 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 three types are:

• The default Work Manager
• Global Work Managers
• Application-scoped Work Managers

These three types of Work Managers are described in the following sections:

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 to Use Work Managers

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

• The default fair share is not sufficient. This usually occurs in situations where one application needs to be given higher priority over another.
• A response time goal is required.
• A minimum thread constraint needs to be specified to avoid server deadlock

Global Work Managers

• You can create Work Managers that are available to all applications and modules deployed on a server. Global Work Managers are created in the WebLogic Administration Console and are 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 that 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. Work Managers can be specified in the following descriptors:

• Weblogic-application.xml
• Weblogic-ejb-jar.xml
• xml

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.  

Using Work Managers, Request Classes, and Constraints

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

• A definition. You may define a Work Managers, Request Classes, or Constraints globally in the domain’s configuration using the Administration Console, (see Environments > Work Managers in the Administration Console) or you may define them in one of the deployment descriptors listed above. In either case, you assign a name to each.
• A mapping. In your deployment descriptors, you reference one of the Work Managers, Request Classes, or Constraints by its name.

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 backward compatibility, it can also name an ExecuteQueue. In addition, we allow dispatch-policy, max-threads, and min-threads, to specify named (or unnamed with a 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 also the schema for these deployment descriptors:

• weblogic-ejb-jar.xml schema
• weblogic-application.xml schema
• xml schema

weblogic-ejb-jar.xml With Work Manager Entries

<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>WorkEJB</ejb-name>

<jndi-name>core_work_ejb_workbean_WorkEJB</jndi-name>

<dispatch-policy>weblogic.kernel.System</dispatch-policy>

</weblogic-enterprise-bean>

<weblogic-enterprise-bean>

<ejb-name>NonSystemWorkEJB</ejb-name>

<jndi-name>core_work_ejb_workbean_NonSystemWorkEJB</jndi-name>

<dispatch-policy>workbean_workmanager</dispatch-policy>

</weblogic-enterprise-bean>

<weblogic-enterprise-bean>

<ejb-name>MinThreadsWorkEJB</ejb-name>

<jndi-name>core_work_ejb_workbean_MinThreadsWorkEJB</jndi-name>

<dispatch-policy>MinThreadsCountFive</dispatch-policy>

</weblogic-enterprise-bean>

<work-manager>

<name>workbean_workmanager</name>

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

<name>minthreads_workmanager</name>

<min-threads-constraint>

<name>MinThreadsCountFive</name>

<count>5</count>

</min-threads-constraint>

</work-manager>

<work-manager>

<name>lowpriority_workmanager</name>

<fair-share-request-class>

<name>low_priority</name>

<fair-share>10</fair-share>

</fair-share-request-class>

</work-manager>

<work-manager>

<name>highpriority_workmanager</name>

<fair-share-request-class>

<name>high_priority</name>

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

</fair-share-request-class>

</work-manager>

<work-manager>

<name>veryhighpriority_workmanager</name>

<fair-share-request-class>

<name>veryhigh_priority</name>

<fair-share>1000</fair-share>

</fair-share-request-class>

</work-manager>

weblogic-ejb-jar.xml with Connection Pool Based Max Thread Constraint

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>

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>

web application descriptor

This Web Application is deployed as part of the Enterprise Application defined in  weblogic-application.xml. 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>

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 discusses 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 which allowed you to create thread-pools to determine how the workload was handled. WebLogic Server still provides Execute Queues for backward compatibility, primarily to facilitate application migration. However, new application development should utilize Work Managers to perform thread management more efficiently. You can enable Execute Queues in the following ways:

• Using the command line option

-Dweblogic.Use81StyleExecuteQueues=true

• Setting the Use81StyleExecuteQueues property via the Kernel MBean in config.xml.

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

• 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.
• If the Work Manager does not implement any constraints, then the global default Execute Queue is used.

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.

Check out our Related Courses

• Weblogic Tutorials
• Introduction to Clustering Weblogic
• Oracle Goldengate Training In Bangalore
• Oracle Weblogic Server Installation