Execute Queues:
The main purpose of having the Execute Queues is to handle the internal and external related requests on WebLogic server. Here,
Internal requests: Communication between the managed servers or communication between adminserver server and managed servers.
External requests: The requests between the applications deployed inside the WebLogic server and redirection requests from WebLogic server to the database, etc.
All these requests are handled using threads. Hence, we can conclude that the Execute Queues are mainly used for thread management. This management is achieved by using different executive queues like weblogic.kernel.default, weblogic.admin. HTTP, weblogic.admin.RMI, etc
Disadvantage:
Thread processing was performed in multiple execute queues. Different classes of work was executed in different queues .So threads are allocated for execution of task in a queue without order and priority, could not control thread usage by altering the number of threads in the default queue.
Work Managers:
In WebLogic Server 9x we had a replacement done to Execute Queues with the introduction of Work Managers. Work Managers are the new advancement of the execute queues or the thread management in WebLogic server .With introduction of Work Managers, WebLogic server helps to prioritize work and allocate the threads based on an execution modal.
The work is then assigned to a thread within the queue that performs the work
You could control thread usage by altering the number of threads in the default queue, or configure custom execute queues to ensure that particular applications had access to a fixed number of execute threads, regardless of overall system load. Administrators can configure a set of scheduling guidelines and associate them with one or more applications, or with particular application components
Example:
You can associate one set of scheduling guidelines for one application, and another set of guidelines for other applications. At run time, WebLogic Server uses these guidelines to assign pending work and enqueued requests to execution threads
To manage work in your applications, you can define one or more of the following Work Manager components in your deployment descriptor or config files.
Request class:
A request class expresses a scheduling guideline that WebLogic Server uses to allocate threads to handle the 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. WebLogic Server takes into account how long it takes for requests to each component to complete.
The mixture of requests from different request classes in the queue at any particular time. For example, more requests than the configured ratio may be processed for a lower priority request class if there are not enough requests from a higher priority request class in the Work Manager queue. Because the ratio is specified in terms of thread-usage time, a larger number of shorter requests could be processed in the same amount of thread-usage time as a smaller number of time-consuming requests.
There are multiple types of request classes, each of which expresses a scheduling guideline in different terms. A Work Manager may specify only one request class
Fair Share Request Class
Response Time Request Class
Context Request Class
Fair Share Request Class:
Specifies the average thread-use time required to process requests. The default fair share value is 50
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.At particular point of time for each module such that the number requests exceed the number of threads. WebLogic Server will allocate 80% of thread-usage time to ModuleA and 20% of the thread-usage time to ModuleB .
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.
Example:
From the previous example ModuleA and ModuleB, have response time goals of 2000 ms and 5000 ms, respectively, and the actual thread use time for an individual request is less than its response time goal. 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, and no "think time" delays between response and request, WebLogic Server will schedule requests for ModuleA and ModuleB to keep the average response time in the ratio 2:5. The actual average response times for ModuleA and ModuleB might be higher or lower than the response time goals, but will be a common fraction or multiple of the stated goal. For example, if the average response time for ModuleA requests is 1,000 ms., the average response time for ModuleB requests is 2,500 ms.
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.
Example:
The context-request-class in Context Request Class assigns a request class to requests based on the value of the request's subject and role of the properties.
A context request class allows you to define request classes in an application's deployment descriptor based on a user's context
Context Request Class
<work-manager>
<name>responsetime_workmanager</name>
<response-time-request-class>
<name>my_response_time</name>
<goal-ms>2000</goal-ms>
</response-time-request-class>
</work-manager>
<work-manager>
<name>context_workmanager</name>
<context-request-class>
<name>test_context</name>
<context-case>
<user-name>system</user-name>
<request-class-name>high_fairshare</request-class-name>
</context-case>
<context-case>
<group-name>everyone</group-name>
<request-class-name>low_fairshare</request-class-name>
</context-case>
</context-request-class>
</work-manager>
Above, we have explained the request classes based on fair share and response time by relating the scheduling to other work using the same request class. A mix of fair share and response time request classes is scheduled with a marked bias in favor of response time scheduling.
Constraints:
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.
Max-thread constrains:
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-thread constrains:
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 constrains: This constraint causes the server to reject requests only when it has reached its capacity. The default is zero. 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.
Thread Stuck Handling In worker manager
By the below given example we can set the work manager in deployment descriptor of the application of two threads that are stuck for longer than 30 seconds, the work manager shuts down , And move the application into admin mode, or mark the server instance as failed.
Stuck-Thread Work Manager
<work-manager>
<name>stuckthread_ workmanager</name>
<work-manager-shutdown-trigger>
<max-stuck-thread-time>30</max-stuck-thread-time>
<stuck-thread-count>2</stuck-thread-count>
</work-manager-shutdown-trigger>
</work-manager>
Work Managers can be specified in the following descriptors:
config.xml
weblogic-application.xml
weblogic-ejb-jar.xml
weblogic.xml
Types of worker manager:
The default Work Manager
Global Work Managers
Application-scoped Work Manager
Default Work Manager:
These are used to handle thread management and perform self-tuning. This Work Manager is used by an application when no other Work Managers are specified in the application’s deployment descriptors
In many situations, the default Work Manager is sufficient for most application requirements. WebLogic Server’s thread-handling algorithms assign each application its own fair share by default. Applications are given equal priority for threads and are prevented from monopolizing them.
Global Work Managers:
These have the scope of the domain. Global Work Managers are created in the WebLogic Administration Console using the following steps:
a) Login to WebLogic Admin Console and click on the left Panel “Work Manager”.
b) Then click on “Lock and Edit” button and click on “New” button from right panel
c) Select “Work Manager” radio button from Select Work Manager Definition type then click on Next.
d) Give the work Manager Name and click Next.
e) Now Target it to any Server or Cluster.
f) Now click on “Finish” and then “Activate Changes”
These are then defined in config.xml.
Application-scoped Work Managers:
In addition to globally-scoped Work Managers, you can also create Work Managers that are available only to a specific application or module. Work Managers can be specified in the following descriptors:
weblogic-application.xml
weblogic-ejb-jar.xml
weblogic.xml
Although from WebLogic server 9x execute queues are not available still you can enable Execute Queues in the following ways it’s called Backward compatibility.
Using the command line option: Dweblogic.Use81StyleExecuteQueues=true
Setting the Use81StyleExecuteQueues property via the Kernel MBean in config.xml
After enabling, Work Managers are converted to Execute Queues based on the following:
1.If the Work Manager implements a minimum or maximum threads constraint, then an Execute Queue is created with the same name as the Work Manager. The thread count of the Execute Queue is based on the value defined in the constraint.
2.If the Work Manager does not implement any constraints, then the global default Execute Queue is used.
The main purpose of having the Execute Queues is to handle the internal and external related requests on WebLogic server. Here,
Internal requests: Communication between the managed servers or communication between adminserver server and managed servers.
External requests: The requests between the applications deployed inside the WebLogic server and redirection requests from WebLogic server to the database, etc.
All these requests are handled using threads. Hence, we can conclude that the Execute Queues are mainly used for thread management. This management is achieved by using different executive queues like weblogic.kernel.default, weblogic.admin. HTTP, weblogic.admin.RMI, etc
Disadvantage:
Thread processing was performed in multiple execute queues. Different classes of work was executed in different queues .So threads are allocated for execution of task in a queue without order and priority, could not control thread usage by altering the number of threads in the default queue.
Work Managers:
In WebLogic Server 9x we had a replacement done to Execute Queues with the introduction of Work Managers. Work Managers are the new advancement of the execute queues or the thread management in WebLogic server .With introduction of Work Managers, WebLogic server helps to prioritize work and allocate the threads based on an execution modal.
The work is then assigned to a thread within the queue that performs the work
You could control thread usage by altering the number of threads in the default queue, or configure custom execute queues to ensure that particular applications had access to a fixed number of execute threads, regardless of overall system load. Administrators can configure a set of scheduling guidelines and associate them with one or more applications, or with particular application components
Example:
You can associate one set of scheduling guidelines for one application, and another set of guidelines for other applications. At run time, WebLogic Server uses these guidelines to assign pending work and enqueued requests to execution threads
To manage work in your applications, you can define one or more of the following Work Manager components in your deployment descriptor or config files.
Request class:
A request class expresses a scheduling guideline that WebLogic Server uses to allocate threads to handle the 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. WebLogic Server takes into account how long it takes for requests to each component to complete.
The mixture of requests from different request classes in the queue at any particular time. For example, more requests than the configured ratio may be processed for a lower priority request class if there are not enough requests from a higher priority request class in the Work Manager queue. Because the ratio is specified in terms of thread-usage time, a larger number of shorter requests could be processed in the same amount of thread-usage time as a smaller number of time-consuming requests.
There are multiple types of request classes, each of which expresses a scheduling guideline in different terms. A Work Manager may specify only one request class
Fair Share Request Class
Response Time Request Class
Context Request Class
Fair Share Request Class:
Specifies the average thread-use time required to process requests. The default fair share value is 50
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.At particular point of time for each module such that the number requests exceed the number of threads. WebLogic Server will allocate 80% of thread-usage time to ModuleA and 20% of the thread-usage time to ModuleB .
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.
Example:
From the previous example ModuleA and ModuleB, have response time goals of 2000 ms and 5000 ms, respectively, and the actual thread use time for an individual request is less than its response time goal. 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, and no "think time" delays between response and request, WebLogic Server will schedule requests for ModuleA and ModuleB to keep the average response time in the ratio 2:5. The actual average response times for ModuleA and ModuleB might be higher or lower than the response time goals, but will be a common fraction or multiple of the stated goal. For example, if the average response time for ModuleA requests is 1,000 ms., the average response time for ModuleB requests is 2,500 ms.
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.
Example:
The context-request-class in Context Request Class assigns a request class to requests based on the value of the request's subject and role of the properties.
A context request class allows you to define request classes in an application's deployment descriptor based on a user's context
Context Request Class
<work-manager>
<name>responsetime_workmanager</name>
<response-time-request-class>
<name>my_response_time</name>
<goal-ms>2000</goal-ms>
</response-time-request-class>
</work-manager>
<work-manager>
<name>context_workmanager</name>
<context-request-class>
<name>test_context</name>
<context-case>
<user-name>system</user-name>
<request-class-name>high_fairshare</request-class-name>
</context-case>
<context-case>
<group-name>everyone</group-name>
<request-class-name>low_fairshare</request-class-name>
</context-case>
</context-request-class>
</work-manager>
Above, we have explained the request classes based on fair share and response time by relating the scheduling to other work using the same request class. A mix of fair share and response time request classes is scheduled with a marked bias in favor of response time scheduling.
Constraints:
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.
Max-thread constrains:
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-thread constrains:
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 constrains: This constraint causes the server to reject requests only when it has reached its capacity. The default is zero. 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.
Thread Stuck Handling In worker manager
By the below given example we can set the work manager in deployment descriptor of the application of two threads that are stuck for longer than 30 seconds, the work manager shuts down , And move the application into admin mode, or mark the server instance as failed.
Stuck-Thread Work Manager
<work-manager>
<name>stuckthread_ workmanager</name>
<work-manager-shutdown-trigger>
<max-stuck-thread-time>30</max-stuck-thread-time>
<stuck-thread-count>2</stuck-thread-count>
</work-manager-shutdown-trigger>
</work-manager>
Work Managers can be specified in the following descriptors:
config.xml
weblogic-application.xml
weblogic-ejb-jar.xml
weblogic.xml
Types of worker manager:
The default Work Manager
Global Work Managers
Application-scoped Work Manager
Default Work Manager:
These are used to handle thread management and perform self-tuning. This Work Manager is used by an application when no other Work Managers are specified in the application’s deployment descriptors
In many situations, the default Work Manager is sufficient for most application requirements. WebLogic Server’s thread-handling algorithms assign each application its own fair share by default. Applications are given equal priority for threads and are prevented from monopolizing them.
Global Work Managers:
These have the scope of the domain. Global Work Managers are created in the WebLogic Administration Console using the following steps:
a) Login to WebLogic Admin Console and click on the left Panel “Work Manager”.
b) Then click on “Lock and Edit” button and click on “New” button from right panel
c) Select “Work Manager” radio button from Select Work Manager Definition type then click on Next.
d) Give the work Manager Name and click Next.
e) Now Target it to any Server or Cluster.
f) Now click on “Finish” and then “Activate Changes”
These are then defined in config.xml.
Application-scoped Work Managers:
In addition to globally-scoped Work Managers, you can also create Work Managers that are available only to a specific application or module. Work Managers can be specified in the following descriptors:
weblogic-application.xml
weblogic-ejb-jar.xml
weblogic.xml
Although from WebLogic server 9x execute queues are not available still you can enable Execute Queues in the following ways it’s called Backward compatibility.
Using the command line option: Dweblogic.Use81StyleExecuteQueues=true
Setting the Use81StyleExecuteQueues property via the Kernel MBean in config.xml
After enabling, Work Managers are converted to Execute Queues based on the following:
1.If the Work Manager implements a minimum or maximum threads constraint, then an Execute Queue is created with the same name as the Work Manager. The thread count of the Execute Queue is based on the value defined in the constraint.
2.If the Work Manager does not implement any constraints, then the global default Execute Queue is used.
3 comments:
very good
very nice blog
very nice blog
Post a Comment