Workload Management in WebLogic Server 9.0
Pages: 1, 2, 3, 4, 5

The WorkManager Minimum Threads Constraint

The minimum threads constraint is another component of a WorkManager, much like a request class. This constraint should be used in very special cases and should not be confused with the thread count parameter in execute queues. The minimum threads constraint takes an integer value that specifies the number of threads that should be assigned to this constraint to prevent server-to-server deadlocks. Usually, all WorkManagers use threads from the common thread pool, and the proportion of thread usage by different WorkManagers is determined by the request class component defined in the previous sections. Threads are dynamically added to the common thread pool to maximize the overall server throughput.

There are special situations where two servers can deadlock if a WorkManager does not get a minimum number of threads. For example, consider when Server A makes an EJB call to Server B, and Server B in turn makes a callback to Server A as a part of the same request processing. In this case, we know that until Server A responds to the callback from Server B, its original request to Server B will not get serviced. This scenario can be addressed in two ways. Configuring a WorkManager in Server A with a high fair share for callback requests from Server B will ensure that those requests get higher priority than new requests arriving at Server A from clients. In addition, adding a minimum threads constraint clause to the WorkManager will ensure that at least some threads in Server A will be able to pick up callback requests from Server B even when all the threads are busy or deadlocked.

A minimum threads constraint is specified like this:

<work-manager>
  <name>MyWorkManager</name>
  <min-threads-constraint>
    <name>minthreads</name>
    <count>3</count>
  </min-threads-constraint>
</work-manager>

The WorkManager Maximum Threads Constraint

The maximum threads constraint can be used to limit the maximum number of concurrent threads given to all WorkManagers that share the constraint. Like the minimum threads constraint, the maximum threads constraint should be used only in special circumstances. Normally, the request classes get their fair share of thread resources, and the maximum number of threads in the common thread pool is limited by throughput considerations. Threads are not added if there is no benefit in overall server throughput. There are cases when the administrator/deployer knows that the maximum number of concurrent threads is bound by the maximum capacity of the JDBC connection pool. For example, all servlet or EJB requests that use a common JDBC connection pool are bound by its maximum pool size. In such circumstances, it is possible to define a maximum threads constraint that refers to the JDBC connection pool. This maximum threads constraint is then shared by all WorkManagers affected by the connection pool size. Here is an example of a maximum threads constraint that uses a JDBC connection pool:

<work-manager>
  <name>MyDataSourceBoundWorkManager</name>
  <max-threads-constraint>
    <name>pool_constraint</name>
    <pool-name>AppScopedDataSource</pool-name>
  </max-threads-constraint>
</work-manager>

Note that AppScopedDataSource refers to the name of the data source that is either application scoped or defined at the server level. The maximum threads constraint changes dynamically as the maximum connection pool size changes.

The maximum threads constraint can also be specified as a number:

<work-manager>
  <name>MyWorkManager</name>
  <max-threads-constraint>
    <name>ejb_maxthreads</name>
    <count>5</count>
  </max-threads-constraint>
</work-manager>

The WorkManager Capacity Constraint

The capacity constraint defines the maximum number of requests that can be queued or are executing at any given point in time. Only requests waiting for threads or those currently under execution are counted. Capacity can be shared across multiple WorkManagers. This means that all WorkManagers that share the capacity are bound by the common limit. Overload action is taken after the capacity is reached. For example, work is refused with a well-known HTTP response code like 503 or a RemoteException in case of RMI calls permitting cluster failover. Overload protection in WebLogic Server 9.0 will be discussed in a forthcoming dev2dev article. Capacity is specified like this:

<work-manager>
  <name>MyWorkManager</name>
  <capacity>
    <name>MyCapacity</name>
    <count>10</count>
  </capacity>
</work-manager>

Interaction Between Different Types of Request Classes and Constraints

In the previous sections, I explained scheduling based on policies such as fair share and response time by relating the scheduling to other work using the same policy. This section explains how different types of policies like request classes and constraints interact with each other.

1. A mix of fair-share and response-time policies is scheduled with a marked bias in favor of response-time scheduling.
2. A minimum threads constraint may increase a fair share. If the minimum threads constraint is not met and there are pending requests that belong to this work set, then it will trump fair share in the sense that a request is scheduled from the minimum threads constrained work set even if its request class has gotten more than its fair share recently. That is why it is important to use a minimum threads constraint carefully to avoid giving a fair share a boost. Note that this behavior is subject to change, and the minimum threads constraint may not give a fair share a boost in a future version—but it is guaranteed that the minimum threads constraint will be honored when the server is almost in a deadlocked state and making little progress.
3. A maximum threads constraint may, but not necessarily, prevent a request class from taking its fair share or meeting its response-time goal. Once the maximum threads constraint is reached, the server will not schedule requests of this constraint type until the number of concurrent executions falls below the limit. The server will then schedule work based on the fair share or response-time goal.