In WebLogic 8, you had the ExecuteQueues to perform some tuning about the number of threads, assigning different scope of execution ...
In WebLogic 9+, the concept of WorkManager has been introduced.
BEA strongly recommends the use of WorkManagers instead of ExecuteQueues.
However, if you want to use the old mechanism, you may by specifying the option "-Dweblogic.Use81StyleExecuteQueues=true" in your JVM startup script.
One of the interesting use of WorkManager is to avoid an overload to a server by specifying a maximum request number.
Beyond that number, the server will reject new requests. Of course, it has a meaning only if you're using a cluster ...
Else, you would have some 5XX exceptions coming back to your users !
One of the prerequisites for that solution to work is that you use the WebLogic plugin,
and that you let the IdemPotent & the Dynamic Server List options set to true (which should be the case by default) in your plugin configuration.
Creating the resources
First, you will have to define a capacity constraint. Target it on the chosen instance.
Then, specify the maximum number of requests your instance can handle.
Then create the wrapping WorkManager and choose the subcomponent previously created (capacity constraint).
Assign that WorkManager to the server, (same instance targetted by the capacity constraint).
Checking the creation
Then check that your WorkManager and the capacity constraint are correctly targetted
You're done.
And when the 101st request arrives on the server, the latter will send a HTTP 503 error.
Combined to the configuration of your plugin, this will dispatch the request to the next WebLogic Server instance in the cluster,
as shown below.
No comments:
Post a Comment