Workload Management in WebLogic Server 9.0

by Naresh Revanuru
03/07/2006

WebLogic WorkManager Configuration

Before I discuss more about how to configure WorkManagers for your application, it is important to note that the default configuration may be good enough. As mentioned earlier, each application gets its own WorkManager with its own default fair share. This means that all applications are treated with equal importance, and applications are prevented from hogging threads. WorkManagers can be configured and associated with requests overriding the default for the following reasons:

  1. The default fair share is not good enough.
  2. A response-time goal needs to be specified.
  3. A possibility of server-to-server deadlock exists, and a minimum threads constraint needs to be specified.
  4. Requests are bound by a common JDBC connection pool, and a maximum threads constraint needs to be specified.

Here are some guidelines on how to configure a WorkManager:

  1. WorkManagers can be application scoped by defining them in weblogic-application.xml. Keeping WorkManager configuration close to the application may help with portability.
  2. Decide if the components such as request classes and constraints in the WorkManager should be shared with other WorkManagers. If so, such components should be declared independently outside of the WorkManagers. Otherwise the components can be declared inside the WorkManager providing exclusive access.
  3. The WebLogic Server Administration Console provides screens for configuring WorkManagers and other related components. WorkManagers created through the console are available server-wide.

As mentioned earlier, WorkManagers can be application scoped or defined globally. WorkManagers can refer by name to independently defined components such as request classes and constraints. The name resolution is handled as follows:

  1. If the request class or constraint can be found within the application, then it is picked up.
  2. If (1) fails, then components at the server level are searched for a match.
  3. If (2) fails, then an exclusive default fair-share request class is created if the request class is being resolved. For constraint and capacity, a null value is returned which means that the WorkManager is unbounded in terms of the number of concurrent threads it gets to use and the number of requests it can enqueue.

Note that the names used while referring to the WorkManager components are the ones defined in the deployment descriptors and not JNDI names. Here is an example of WorkManager configuration defined in an application:



<weblogic-application>
  ...  
  <max-threads-constraint>
    <name>MyConstraint</name>
    <pool-name>MyDataSource</pool-name>
  </max-threads-constraint>
  ...
  <work-manager>
    <name>MyAppScopedWorkManager-1</name>
    <fair-share-request-class>
      <name>high_fairshare</name>
      <fair-share>80</fair-share>
    </fair-share-request-class>
    <max-threads-constraint-name>MyConstraint
                            </max-threads-constraint-name>
  </work-manager>
    <work-manager>
    <name>MyAppScopedWorkManager-2</name>
    <fair-share-request-class>
    <name>high_fairshare</name>
    <fair-share>20</fair-share>
    </fair-share-request-class>
    <max-threads-constraint-name>MyConstraint
                           </max-threads-constraint-name>
  </work-manager>
  ...
</weblogic-application>

Note how the two WorkManagers are sharing the same maximum threads constraint by referring to the constraint by name.

Setting the Dispatch Policy

Now that we've looked at configuring WorkManagers, let's examine how to link a WorkManager with requests. You can do this by defining a dispatch-policy. For servlets, this is accomplished by setting a dispatch-policy initialization parameter; for EJBs you have to use the dispatch-policy element that existed in the earlier releases. In the earlier releases, the dispatch policy referred to the name of an execute queue. In WebLogic Server 9.0, the same dispatch-policy element is used to refer to WorkManagers. The dispatch-policy resolution happens as follows:

  1. If a WorkManager with the dispatch-policy name can be found within the same application, it is resolved to that.
  2. If (1) fails, then a WorkManager match is attempted at the server level.
  3. If (2) fails, then a warning message is printed in the server logs, and the application default WorkManager is used.

Here is how to set a dispatch policy in a servlet in web.xml:



<web-app>
  <servlet>
    <servlet-name>WorkServlet</servlet-name>
    <servlet-class>workservlet.WorkServlet</servlet-class>
    <init-param>

      <param-name>wl-dispatch-policy</param-name>       <param-value>MyAppScopedWorkManager-1</param-value>
    </init-param>
  </servlet>
</web-app>

The configuration means that all WorkServlet invocations should use the MyAppScopedWorkManager-1 WorkManager.

Here is another use of the dispatch-policy element, in weblogic-ejb-jar.xml:



<weblogic-ejb-jar>
  <weblogic-enterprise-bean>
    <ejb-name>WorkEJB</ejb-name>
    <jndi-name>WorkEJB</jndi-name>

 <dispatch-policy>MyAppScopedWorkManager-2</dispatch-policy>
  </weblogic-enterprise-bean>
  ...
</weblogic-ejb-jar>

The two examples above use MyAppScopedWorkManager-1 and MyAppScopedWorkManager-2, which are WorkManagers defined at the application level in the previous section.

How Are WorkManagers Resolved During Runtime Execution?

As mentioned in the previous section, applications set a dispatch policy to associate request entry points with named WebLogic WorkManagers. During deployment, each module looks at the configured dispatch policy and maps the servlet or EJB method call to a particular WorkManager instance. It is possible to map multiple method calls to a single WorkManager instance. All user requests made to that particular method call or servlet invocation will be automatically dispatched to the associated WorkManager and therefore get its properties. Applications can be redeployed with a new dispatch policy. 

There are plans to support deployment in WebLogic Server 9.1. This is subject to change. Check the 9.1 release notes when they become available for confirmation.

Using execute queues instead of WorkManagers

It is possible to turn off WorkManagers and self-tuning mode in WebLogic Server 9.0 and use execute queues. Just start the server with -Dweblogic.Use81StyleExecuteQueues=true or set this KernelMBean property in config.xml. It is recommended that you set the attribute in config.xml instead of using the system property since it will turn on execute queue configuration and monitoring in the WebLogic console. Here is an example config.xml snippet:



<server>
  <name>myserver</name>
  <use81-style-execute-queues>true</use81-style-execute-queues>
  <listen-address/>
</server>

Turning on this property will disable all WorkManager configuration and the thread self-tuning mode. Users will get the exact WebLogic Server 8.1 execute queue behavior. When this property is enabled, WorkManager configurations are converted into execute queues using the following steps:

  1. If the WorkManager has a minimum threads constraint and/or maximum threads constraint, then a dedicated execute queue is created with the WorkManager name. The thread count of the execute queue is based on the constraint.
  2. If the WorkManager has no constraints, then the global default execute queue is used. A dedicated execute queue is not created.

This flag is useful for applications migrated from version 8.1 that are still not taking advantage of the self-tuning thread pool and WorkManagers. Perhaps the customers want to get their applications into production while investigating the use of the WorkManagers.

The server logs should have an entry like this when this flag is enabled :



<Sep 30, 2005 11:02:52 AM PDT>
 <Notice> <Kernel> <BEA-000805> <Self-tuning thread pool
 is disabled. An execute queue will be created for 
 each WorkManager definition.>

Migrating from WebLogic Server 8.1 to WebLogic Server 9.0

An application migrated from WebLogic Server 8.1 to WebLogic Server 9.0 will still have execute queues in the server configuration if they were present before the migration. Automatic conversion of execute queues to WorkManagers is not possible since in some cases WorkManagers are not required. If a WebLogic Server 8.1 application with execute queues is deployed in a WebLogic Server 9.0 server, then the configured execute queues are created and used by requests. Please note that requests without a dispatch-policy will continue to use the self-tuning thread pool. Only requests whose dispatch-policy maps to an execute queue will use the configured execute queue.

Runtime Monitoring Support

Extensive monitoring support is provided through RuntimeMBeans. Administrators can monitor individual WorkManagers, constraints, request classes, and the common self-tuning thread pool parameters. The WebLogic console also exposes a lot of this information under the appropriate tabs. Administrators can go to a particular application and then monitor all the WorkManager components related to that application. The common thread pool parameters can be monitored under the server monitoring console tab. Here are some of the RuntimeMBeans that provide information about workload management:

  1. ThreadPoolRuntimeMBean under the ServerRuntimeMBean: Provides monitoring information about the self-tuning thread pool.
  2. WorkManagerRuntimeMBeans under the ApplicationRuntimeMBean: Contain information about the individual WorkManagers in the application. The ApplicationRuntimeMBean is a child of ServerRuntimeMBean.
  3. RequestClassRuntimeMBeans, MinThreadsConstraintRuntimeMBeans, and MaxThreadsConstraintRuntimeMBeans under the ApplicationRuntimeMBean: Provide information about WorkManager components that are shared by multiple WorkManagers.

Thread Dump Changes

In WebLogic Server 8.1 and earlier releases, threads belonging to execute queues could be identified in the thread dump using the name of the execute queue. That has changed in WebLogic Server 9.0. Since all WorkManagers use the common thread pool, thread dumps will not be able to identify which threads belong to which WorkManagers. This is because threads are shared by all WorkManagers. All execute threads have the term "self-tuning" in their names to indicate that they belong to the common self-tuning pool. The thread names are prepended with their states. The three states that appear in the thread names are:

  1. ACTIVE: The thread is active and is executing work or is ready to pick up work when it arrives.
  2. STANDBY: The thread is removed from the active thread pool and is not picking up work. It can still execute work from the minimum threads constraint work set if the constraint is not met. The self-tuning implementation has removed this thread from the active pool since it is not improving throughput. It can be moved back into the active thread pool if needed later.
  3. STUCK: A thread is stuck executing work for more than the configured stuck thread interval. The thread could be stuck due to a deadlock or a slow responding back end connection.

Timer and WorkManager Specification Support

The Timer and WorkManager specification standardizes how applications submit asynchronous work in an application server. WebLogic Server 9.0 implements this specification, providing applications a handle to the internal self-tuning thread pool implementation. Let's call the WorkManagers found in the Timer and WorkManager specification, TWM WorkManagers. Applications can look up a TWM WorkManager through JNDI and submit work for asynchronous execution. The important thing to note here is that the TWM WorkManager can be associated with any WebLogic WorkManager configured using deployment descriptors by using the WorkManager name in the resource-ref entry. Here is an example:



<ejb-jar>
  <enterprise-beans>
    <session>
      <ejb-name>WorkEJB</ejb-name>
      ...  
      <resource-ref>
        <res-ref-name>MyAppScopedWorkManager-1</res-ref-name>
        <res-type>commonj.work.WorkManager</res-type>
        <res-auth>Container</res-auth>
        <res-sharing-scope>Shareable</res-sharing-scope>
      </resource-ref>
      ...
</ejb-jar>

Here the res-ref-name points to the name of the WebLogic WorkManager defined in weblogic-application.xml. If the WebLogic WorkManager cannot be found, then the application default is used. Application code can look up the TWM WorkManager as follows:



InitialContext ic = new InitialContext();

commonj.work.WorkManager mgr =
              (commonj.work.WorkManager)
              ic.lookup("java:comp/env/MyAppScopedWorkManager-1");
mgr.schedule(myWork);

Conclusion

BEA WebLogic Server 9.0 has introduced advanced techniques in workload management. Instead of requiring administrators to set low-level kernel parameters such as thread counts, and configuring static thread pools, it now provides higher level concepts like fair shares, response-time goals, and context-based shares for differentiated service. Thread count is self-tuned to maximize throughput. WebLogic Server 9.0 also provides a programmatic way to access the thread pool so that application developers can get the same benefits internal subsystems receive. A lot of monitoring support has also been added. We hope all these improvements will result in a better user experience.

Naresh Revanuru Naresh Revanuru is a senior software engineer working in the BEA WebLogic engineering team. Naresh is the team lead for the BEA WebLogic core/clustering subsystem.