This content has been marked as final. Show 4 replies
It depends on your situation, maybe the following gives you some guidelines as to how to configure a workmanager for your situation.
Work managers provide a way to describe how the server partitions its resources across applications.
To describe resource partitioning, WebLogic Server work managers contain four component types:
2.Minimum Threads Constraint
3.Maximum Threads Constraint
Think of a request class as a mechanism to define the runtime behavior of the set of requests to which it is associated. All requests that share a runtime behavior should share a request class. For example, if all of the HTTP requests within your web applications are equally important, you should associate your web applications with the same request class so that they get equal runtime prioritization when being dispatched by the server. By default, each application belongs to its own request class. WebLogic Server supports three request class types:
Fair Share Request Class - A fair share request class specifies the relative thread usage time of an application as compared to other applications running in the same instance. Imagine a managed server with two applications deployed, A and B. Application A uses a work manager with a fair share of 50 and Application B uses a work manager with a fair share of 150. When the server is receiving a steady stream of requests from both applications that exceed the number of execute threads, the server will assign Application A's requests to 25% of the available threads and Application B's requests to 75% of the available threads, assuming that requests for both applications, on average, take the same amount of time to execute. The allowable values of a fair share request class are 1 to 1000. Each application that uses a work manager that does not explicitly reference a request class gets an exclusive fair share value of 50.
Response Time Request Class - A response time request class specifies the target response time in milliseconds. Using our previous example, imagine that Application A uses a work manager with a response time of 3000 milliseconds and Application B uses a work manager with a response time of 5000 milliseconds. When the server is receiving a steady stream of requests from both applications that exceed the number of execute threads, the server will keep the average response times of the two applications in a 3 to 5 ratio, where the actual response times will be some fraction or multiple of the response time goal.
Context Request Class - A context request class is a compound class that maps between the context of a request and a fair share or response time request class. A context request class supports using the authenticated user and group names to map to different fair share or response time request classes. For example, a stock quote application might assign a higher fair share to logged-in users (which implies that they have accounts) by routing all requests associated with the built-in group name users to which all authenticated users belong to a higher fair share request class, and all requests associated with the built-in user name <anonymous> to a lower fair share request class.
Constraints allow you to set limits on what a work manager can do. By default, a work manager has no constraints. The minimum thread constraint has nothing to do with the minimum size of the execute thread pool. Instead, it allows you to ensure that the server will have a certain number of threads available for processing requests associated with work managers using this constraint. This is really only useful to prevent deadlock in certain server-to-server callback scenarios.
Imagine that Application A runs on Managed Server 1 and Application B runs on Managed Server 2. If Application A makes an EJB call to Application B and Application B calls back to Application A (or any other application running on Managed Server 1) while processing the EJB call, it is possible to deadlock the two managed servers. If all of Managed Server 1's threads are waiting on the EJB call to Application B to respond, Managed Server 1 will not have any threads available to process the callback requests and the two servers will deadlock waiting on each other. To prevent this deadlock situation, you might assign the callback requests from Application B a higher fair share than the calls generating the EJB calls to Application B. You might also add a minimum threads constraint for the callbacks to ensure that some threads will always be available for processing callbacks.
Maximum thread constraints are useful in a number of situations. For example, if a particular type of request requires a database connection, you might want to set a maximum thread constraint to a value equal to the maximum number of database connections available to your application so that execute threads will not block waiting for a connection to be available. This example is such a common use case that the maximum thread constraint supports either specifying a numeric value or the name of a WebLogic Server–defined JDBC data source. In the latter case, the maximum thread constraint value changes as the maximum size of the JDBC data source's connection pool changes.
Capacity constraints allow you to specify the maximum number of requests a server will accept. The capacity constraint gives you a mechanism to prevent the execute queue overload condition. When determining capacity, the server counts all requests currently executing on an execute thread and all requests waiting in the execute queue. When a capacity constraint is reached, the server takes overload protective action; for example, by returning an HTTP 503 response to indicate that the server is too busy or returning a RemoteException for RMI calls to allow the request to fail over to another server in the cluster. WebLogic Server also provides a Shared Capacity for Work Managers parameter that limits the total capacity of the server.
During certain types of failure conditions, execute threads may block for extended periods of time waiting for slow backend systems or TCP/IP timeouts in the case of machine or network failures. These conditions can cause execute threads to block for minutes at a time. If the server's incoming request load is high enough, all available execute threads will be blocked and the server will create more execute threads in an attempt to continue doing useful work. Because the server does not understand the nature of the problem or the applications it is servicing, it cannot make an intelligent decision about whether creating new execute threads will in fact help. The real issue in these situations is that the server is unable to process any requests because of this failure condition. Your first thought might be to create a maximum thread constraint to prevent the server from creating too many threads; however, this would be treating the symptom and not the root cause. The real problem is that the requests keep piling up in its execute queue. There is no point in the server accepting work if the time it will take to process that work exceeds the time for which the clients are willing to wait on the response. A better way to protect the server in these situations is to define a capacity constraint so that the server starts rejecting work when it is unable to keep up. By combining a capacity constraint with proper tuning of the stuck thread detection capability, you can protect the server from overloading itself during these types of failures.