深入理解wls10的workmanager

分多个测试场景：

前提：线程属于自调整；没有使用-Dweblogic.threadpool.MaxPoolSize=20

   

1.       为什么新建了一个全局的workmanager、最大线程限制，并target到adminserver；当发布application到adminserver后，(但没有修改weblogic.xml，具体是指没有为这个应用指定workmanager);最大线程限制没有起作用呢？

2.       新建了一个全局的workmanager、最大线程限制，naming 为 default，并target到adminserver，发布application后，线程限制起作用了

3.       default的workmanager是没有设置线程限制的

4.       新建了一个应用范围的workmanager后，线程的限制对这个应用起作用了，但对另外的一个应用不会产生影响。

5.       新建了一个全局的workmanager，并target到adminserver；当发布application到adminserver后，(修改weblogic.xml，具体是指为这个应用指定workmanager);最大线程限制起作用了

6.       新建了一个全局的workmanager（a），并target到adminserver；当发布2个application到adminserver后，(修改weblogic.xml，具体是指为每一个应用指定workmanager（a）);最大线程限制起作用了，最大线程数＝applicationA 个数+   applicationB个数

 

思考

1、  没有建workmanager，假如在一个server上deploy了2个application；只要其中一个应用不断产生stuck thread，会拖垮整个server

2、  没有建workmanager，假如在一个server上deploy了2个application；只要其中一个应用不断产生stuck thread，此时会对另一个应用的访问带来很大影响；直至拖垮整个server

 

解决方案

 

1.       线程还是使用自调整，但为每一个应用定义一个应用范围的workmanager，并且定义capaticy 容量（WebLogic Server 开始拒绝请求前可以排队或执行的请求的总数），以免积累了大量请求

上图定义了capacity，一旦超过后健康状况就为 overload了

注意: capacity＝正在执行的+等待的

假如：最大线程限制为3个   capacity为5个；当有3个阻塞线程时，此时再来2个请求，3+2＝5，server状态为 warning,（因有stuck thread）

再来一个请求后，server状态立即变为 overload了，此时访问就变为下图的结果了

 

 

 

建立全局范围的workmanager，然后要应用在weblogic.xml去调用，这样做的好处是，应用层面的配置少了很多，只需要加上一句话就行了。