WebLogic Work Managers Test

The WebLogic Server allows you to configure how your application prioitizes the execution of its work based on rules you define and by monitoring actual runtime performance. You define the rules and constraints for your application by defining a Work Manager and applying it either globally to WebLogic Server domain or to a specific application component.

This test monitors the requests to applications, and helps analyze how the work manager mapped to each application is managing the requests. By closely observing the variations to the measures reported by this test, you can quickly identify current/potential application slowdowns, and figure out whether changes in the corresponding work manager specification can improve application performance.

Target of the test : A WebLogic Application Server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for every work manager on the WebLogic server being monitored.

Configurable parameters for the test
Parameter Description

Test Period

How often should the test be executed.


The IP address of the host for which this test is to be configured.


The port at which the specified host listens. By default, this is NULL.

AdminServerHost and AdminServerPort

In some highly secured environments, the eG agent may not be able to collect certain critical metrics related to JDBC from a managed WebLogic server. In such cases, to enable the eG agent to collect the required metrics, you should specify the IP address and Port of the WebLogic admin server to which the managed WebLogic server is associated with. This will enable the eG agent to connect to the WebLogic admin server and collect the required metrics pertaining to the managed WebLogic server. Specify the IP address and Port of the WebLogic admin server in the AdminServerHost and AdminServerPort text boxes. By default, these parameters are set to none.


Specify the duration (in seconds) within which the eG agent should receive the response from the eGurkha WAR file deployed on the WebLogic server in this text box. By default, this is set to is 120 seconds.


The admin user name of the WebLogic server being monitored.


The password of the specified admin user.

Confirm Password

Confirm the password by retyping it here.


If the specified password needs to be encrypted, set the EncryptPass flag to Yes. Otherwise, set it to No. By default, the Yes option will be selected.


If the UseWarFile flag is set to No, then make sure that the EncryptPass flag is also set to No.


Indicate whether the SSL (Secured Socket Layer) is to be used to connect to the WebLogic server.


The name of the specific server instance to be monitored for a WebLogic server (the default value is "localhome")


The URL to be accessed to collect metrics pertaining to the WebLogic server. By default, this test connects to a managed WebLogic server and attempts to obtain the metrics of interest by accessing the local Mbeans of the server. This parameter can be changed to a value of http://<adminserverIP>:<adminserverPort>. In this case, the test connects to the WebLogic admin server to collect metrics pertaining to the managed server (specified by the Host and Port). The URL setting provides the administrator with the flexibility of determining the WebLogic monitoring configuration to use.


If the admin server is to be used for collecting measures for all the managed WebLogic servers, then it is mandatory that the egurkha war file is deployed to the admin server, and it is up and running. 


The Version text box indicates the version of the Weblogic server to be managed. The default value is "none", in which case the test auto-discovers the weblogic version. If the value of this parameter is not "none", the test uses the value provided (e.g., 7.0) as the weblogic version (i.e., it does not auto-discover the weblogic server version). This parameter has been added to address cases when the eG agent is not able to discover the WebLogic server version.


This flag indicates whether/not monitoring is to be done using a Web archive file deployed on the WebLogic server (in which case, HTTP/HTTPS is used by the server to connect to the server). If this flag is set to No, the agent directly connects to the WebLogic server using the T3 protocol (no other file needs to be deployed on the WebLogic server for this to work). Note that the T3 protocol-based support is available for WebLogic servers ver.9 and above. Also, if the UseWarFile parameter is set to No, make sure that the EncryptPass parameter is set to No as well.  

When monitoring a WebLogic server deployed on a Unix platform particularly, if the UseWarFile parameter is set to No, you have to make sure that the eG agent install user is added to the WebLogic users group.


Specify the location of the WebLogic server's java archive (Jar) file. If the UseWarFile flag is set to No, then the weblogic.jar file specified here is used to connect to the corresponding WebLogic server using the T3 protocol. Note that the T3 protocol-based support is available for WebLogic servers ver.9 and above.

Measurements made by the test
Measurement Description Measurement Unit Interpretation

Completed requests

Indicates the number of requests that were successfully serviced by the work manager mapped to this application.



Pending requests

Indicates the number of requests to this application that are waiting in the queue.





A large number of pending requests to an application could indicate a bottleneck in the request processing ability of that application. If too many applications on the server support long-winding request queues, it can ultimately overload the server, and eventually choke its performance. It is therefore essential to quickly isolate those applications that could be experiencing issues with request processing, and then initiate the relevant remedial action on them. Comparing the value of this measure across applications will enable you to accurately identify which application has the maximum number of pending requests. Once the application is spotted, you may want to observe the variations in the pending requests count over time for that application. If you find that the value of this measure keeps increasing with time for that application, further investigation may be necessary to determine the reasons for the same. One of the possible reasons for this could be the lack of sufficient threads. Incoming requests to an application cannot be processed if adequate threads are unavailable; such requests will hence be in queue until such time that the server allocates more threads to the application.

As already stated, the WebLogic server prioritizes work and allocates threads to an application based on the rules and constraints defined within the work manager that is either defined globally or mapped specifically to that application. Therefore, in the event of a slow down in the request processing rate of an application, you can consider fine-tuning its associated work manager definition, so as to ensure the uninterrupted processing of requests. A typical work manager definition should include one request class and one/more thread constraints. 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. A work manager can specify any one of the below-mentioned request classes:

  • Fair share request class: This 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 requests exceed the number of threads, WebLogic Server will allocate 80% and 20% of the thread-usage time to ModuleA and ModuleB, respectively.
  • 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 requests so that the average wait for requests with the class is proportional to its tolerable waiting time.
  • 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.

A constraint defines 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.
  • 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.

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

Indicates the number of threads that are considered to be stuck on the basis of any thread constraints.


WebLogic Server diagnoses a thread as stuck if it is continually working (not idle) for a set period of time. You can tune a server's thread detection behavior by changing the length of time before a thread is diagnosed as stuck, and by changing the frequency with which the server checks for stuck threads.

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.