紧急求助：线程WebContainer : 已活动了毫秒，可能被挂起

个人感觉还是看javacore
联合多次问题出现的javacore，看挂起的线程堆栈是不是在做同一件事。收起

IBM_CS_THREAD_SCHED_DETECT_PERIOD 参数决定延迟检测线程多长时间运行一次.默认值是30秒.
IBM_CS_THREAD_SCHED_DETECT_ERROR 参数决定多长时间的延迟需要被用这个警告信息记录在日志中.
其实这个方法只是用于优化系统消除线程调度延迟，不解决实际问题，具体的可能需要javacore来做进一步定位收起

关于司令给的参数介绍参考下面的官方文档：
http://www-01.ibm.com/support/docview.wss?uid=swg21236327

这其实是治标不治本的做法，正确思路还是应该看系统到底堵在哪儿了。在问题发生时候kill 几个javacore，很快就能看到是什么线程hang住了，然后分析室应用的还是websphere自己的。收起

我曾经碰到过一次线程挂起的情况，属于was web container的BUG，在版本6.1上会出现。
不知道楼主的问题现象是什么，SystemErr和SystemOut详细日志看看。
我那次的解决方法是：
在webcontainer custom property中添加参数：
com.ibm.ws.webcontainer.channelwritetype=sync
或者打补丁：PK72336
参考资料：
http://www-01.ibm.com/support/docview.wss?rs=0&uid=swg24020800


另外也可能是程序问题，导致事务陷入死循环之类的，这类可以通过检测试试：
1.应用服务应该是正常，比如应用程序的其它功能点正常
2.cpu占用资源比较多，至少有一个core是高负荷
这类情况的话，建议打开trace日志复现问题，并从javacore文件着手，看看应用程序到底在做什么

当然还得排除数据源和数据库的问题，这个可以通过其它应用程序连接到同一DB测试排除收起

这个要具体问题具体分析收起

需要日志和javacore文件收起

顶一下 这位仁兄  期待这种讲座的出现 ^_^收起

楼上说的没错, 线程挂起的可能有很多，先用kill -3 杀一个java dump下来看看， 查找里面的 WebContainer : 137 在干什么，为什么会被挂起这么长时间，然后对具体的问题进行诊断。收起

哇，这个复杂了
线程挂起的的原因还是很多的，大概以下几点，可慢慢尝试排除：
1、程序出现死循环，这个检查一下cpu使用率，要是Cpu使用率到达100%，就有可能这个原因；
2、程序所用之sql问题，长时间无返回导致线程挂起，检查一下数据库服务器是否有这样的session，顺便问下你用的什么数据库；
3、HeapSize设置问题，太小会导致垃圾回收频繁，导致反应过慢，这个也常常导致Cpu使用率极高，最后搞到java core dump了，你可以dump文件传上来让大家看一眼；调整的话Max HeapSize你可以调到1G看看，前提是要看你有多少内存了，如果只有2g你就不要乱来了。
4、有些人认为和线程池大小有关，看你的Log如果只有2个线程挂起就导致系统无法连接的话，可以尝试把最大线程提高点看看了，可以到 “应用程序服务器-》server_name-》线程池-》WebContainer ”去调整
5、如果生成了dump文件的话，就可以分析文件，更准确一些；

不过基本上来讲，大家的意见是应该算一致的，调整参数可以减缓挂掉的频率，要彻底解决应该从应用程序着手收起

参数调整起来相对好办些，斑竹能否开个讲座，专门介绍下如何分析日志，找到代码中的“真凶”呀收起