BEA-000337 Feb 1, 2007 11:01:05 AM EST Error WebLogicServer ExecuteThread: '14' for queue: 'weblogic.kernel.Default' has been busy for "72" seconds working on the request "connection82.session95", which is more than the configured time (StuckThreadMaxTime) of "60" seconds.
这样的信息只是一个提示,告诉最终用户某个执行线程执行了多长时间(只有执行时间超过StuckThread-MaxTime,默认600秒),用户可以根据这些信息,分析对应的请求执行了这么长时间是否正常,如果在预期或可以接受范围内,不用作任何干预,否则我们需要借助于thread dump分析执行时间的瓶颈。出现这样的警告信息,weblogic不会对这样的线程作任何操作(weblogic无法识别这么长的执行时间是不是用户所预期的,比如报表操作、文件传输等本身可能就很耗时),直到线程结束。线程能执行结束还好,如果是死锁呢? 这样的线程会一直被挂着,直到weblogic重启。重启对于很多生产系统而言是最后的选择,那么我们有什么方法来避免重启呢? Weblogic9以后,线程管理方面work manager代替了早期的thread pool,而且work manager提供了stuck thread的管理,比如出现几个stuck thread后,我们可以要求work manager停止应用,避免更多的线程被stuck。weblogic停止应用只是不提供服务,但还是不会影响正在执行的线程。
曾经不止一次的被客户问道我们能否中断这样的线程,从weblogic层面来看,这是mission impossible。现在有了TI,我们可以通过它干掉这样的线程。
要干掉这样的线程,首先要借助thread dump拿到线程名,我们将以线程名为filter。Thread dump信息如下:
"[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=6 tid=0x2b25a800 nid=0x3c0 waiting on condition [0x2e08f000..0x2e08fa14]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
......
上面这个线程的名字就是:[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'
为了能正确的attach上JVM,启动的时候需要加上如下的JAVA_OPTIONS,
private VirtualMachine connectVM(){
VirtualMachineManager vmm = Bootstrap.virtualMachineManager();
List connectors = vmm.attachingConnectors();
Connector conn = null;
AttachingConnector socketAttachingConnector = null;
/*
* host and port should be set here
*/