BEA-002936 : maximum thread constraint is reached | Weblogic

We were getting below message in server log files and there were many of these entries.

The following message is repeatedly seen in the server log file:

<BEA-002936> maximum thread constraint weblogic.jms.<JMS_Server_NAME>.Limited is reached

Exact Error in log:

####<Jul 28, 2011 1:51:36 PM CEST> <Info> <WorkManager> <gaddai87> <managed1> <weblogic.timers.TimerThread> <<WLS Kernel>> <> <> <1309521096408> 
<WL-002936> <maximum thread constraint weblogic.jms.JMSServer1.Limited is reached>

 

Solution

This message is only informational and can be safely ignored. Messages will still be dispatched without issue.

WebLogic Server associates some internal work managers whenever a JMS server is created:

weblogic.jms.<JMSServer_NAME>.AsyncPush
weblogic.jms.<JMSServer_NAME>.Limited
weblogic.jms.<JMSServer_NAME>.System

 

– weblogic.jms.NAME.AsyncPush:
Used to push messages to consumers with async message listeners.
Min threads = 1, max threads = unlimited, high fair share

– weblogic.jms.NAME.Limited:
Used for expiring timeouts in the messaging kernel for expiration time and “unborn” messages.
Also used for certain administrative clean-up operations.
Min threads = 1, max threads = 8, normal fair share.

– weblogic.jms.NAME.System:
Used everywhere else that a particular back end schedules work.
Min threads = 1, max threads = unlimited, high fair share.

These self-tuning work managers have a limited thread count (8) to prevent them from allocating hundreds of threads under load. WLS will log an informational message whenever the work manager max constraint limit is reached. This limit is internal and cannot be changed.

The general concept for work managers is that they will expand up to the maximum limit and then shrink back when the load returns to normal. However the shrinking does not start unless there is a certain number of threads in idle state. Hence, if the work managers for the JMS server had an higher limit and in the situation where there had been high load, the threads would have increased but would have never reduced unless the idle limit had been reached. This could have had a bigger performance impact considering that the JMS messaging kernel needs to handle millions of messages. So to prevent this the work managers are created with a limited number of threads. The trade-off is that the server will log this warning message, but this has no impact on performance.

 

WLS work manager configuration supports three different types of constraints – minimum threads, maximum threads, and capacity constraints.

 

 

Minimum Threads Constraint

According to the WLS documentation, the minimum threads constraint “guarantees the number of threads the server will allocate to affected requests to avoid deadlocks.” It makes sure that during periods of high workloads, there would still be a certain number of threads from the self-tuning thread pool available to process work requests for all work managers that reference the minimum threads constraint.

Suppose WM1 is modified to reference a minimum threads constraint C1 with a value of 2, and that it is the only work manager referencing C1. If a work request for WM1 is scheduled when there are available threads in the thread pool, WLS will pick an idle thread for processing the work regardless of whether WM1 references any minimum threads constraint. However, if the work is scheduled during times of high work load and that there are no available threads in the self-tuning thread pool, WLS will first check and see how many threads in the thread pool are currently processing work requests for WM1. In this example, if there are fewer than 2 threads, WLS would create a new thread to handle the work request for WM1. However, if there are already 2 threads in the self tuning thread pool that are executing work on behalf of WM1, the new work request would be put into a queue just like in the case when there is no minimum threads constraint being configured.

Maximum Threads Constraint

The maximum threads constraint “limits the number of concurrent threads executing requests from the constrained work set” according to the WLS documentation. It limits the number of threads in the self-tuning thread pool that can be used at any time for executing work for all work managers that references the same constraint. It is not, however, used for limiting the size of the self-tuning thread pool.

More than one work manager can reference the same maximum threads constraint, and any threads processing requests from any of these work manager would count against the limit configured in the maximum threads constraint. This is useful for limiting thread usages for related work managers.

Suppose a maximum threads constraint C2 is defined with a value of 10 and only one work manager WM3 is defined to use C2 as its maximum threads constraint. When 10 threads from the thread pool are already processing work requests for WM3, any additional work requests for WM3 will be put on a queue for C2 even if there are idle threads available in the self-tuning thread pool. The queued requests will be picked up for processing in the same order as they arrived when work requests for WM3 are completed.
Like the minimum threads constraint, the maximum threads constraint is not designed as a mean to prioritize workloads among different work managers. It is most useful when there are other known limitations where a hard upper limit should be put on the number of threads that should be assigned for processing work requests, and that allocating more threads for processing the workload would not increase the overall throughput.

 

 

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.