存档

‘排错’ 分类的存档

WebSphere的类加载机制和故障排查

2009年5月27日 hashei 没有评论

在部署WebSphere应用的过程中，经常会发生诸如：ClassCastException、ClassNotFoundException、NoClassDefFoundException、UnsatisfiedLinkError的错误。这种有关“类”（Class）的错误，往往来无影——开发环境好的，怎么在生产环境就有问题；而且去无踪——单独建立一个Profile部署一下就没问题了，把Jar包换个目录就OK了。其实要解决这些怪异的问题，首先要了解WebSphere的类加载（Class loader）机制。

下文主要内容来自http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/welcome_nd.html 和IBM developworks中的《如何在WebSphere中解决jar包冲突》一文，我把个人觉得最容易理解的部分总结在一起，方便学习和快速的解决问题。

使用的类装入器以及使用顺序

WebSphere Application Server 的运行时环境按以下顺序使用下列类装入器来查找和装入应用程序的新类：

  1. Java 虚拟机创建的引导程序、扩展和 CLASSPATH 类装入器引导程序类装入器使用引导类路径（通常是 jre/lib 中的类）找到并装入类。扩展类装入器使用系统属性 java.ext.dirs（通常是 jre/lib/ext）找到并装入类。CLASSPATH 类装入器使用 CLASSPATH 环境变量查找和装入类。CLASSPATH 类装入器装入 WebSphere Application Server 产品在 j2ee.jar 文件中提供的 Java 2 Platform, Enterprise Edition（J2EE）应用程序编程接口（API）。由于这个类装入器装入 J2EE API，所以，可以将依赖于 J2EE API 的库添加到类路径系统属性中以扩展服务器类路径。但是，扩展服务器的类路径的首选方法是添加共享库。
  2. WebSphere 扩展类装入器WebSphere 扩展类装入器装入在运行时需要的 WebSphere Application Server 类。扩展类装入器使用 ws.ext.dirs 系统属性来确定装入类时所使用的路径。ws.ext.dirs 类路径中的每个目录和这些目录中的每个 Java 归档（JAR）文件或 ZIP 文件都添加到此类装入器使用的类路径中。如果安装在服务器上的应用程序模块引用了与资源提供程序相关联的资源，并且该提供程序指定了资源驱动程序的目录名称，那么 WebSphere 扩展类装入器还将资源提供程序类装入到服务器中。
  3. 一个或多个应用程序模块类装入器，它们负责装入在服务器中运行的企业应用程序的元素应用程序元素可以是 Web 模块、企业 bean（EJB）模块、资源适配器归档（RAR 文件）和依赖项 JAR 文件。应用程序类装入器按照 J2EE 类装入规则从企业应用程序装入类和 JAR 文件。WebSphere Application Server 允许使共享库与应用程序相关联。
  4. 零个或多个 Web 模块类装入器缺省情况下，Web 模块类装入器装入 WEB-INF/classes 和 WEB-INF/lib 目录的内容。Web 模块类装入器是应用程序类装入器的子代。可以指定使用应用程序类装入器来装入 Web 模块的内容，而不是使用 Web 模块类装入器来装入这些内容。

阅读全文…

分类: Websphere系列, 排错 标签: ,

一次因为系统参数而导致的WAS无响应

2009年4月30日 admin 1 条评论

最近一个项目在做压力测试的时候，压力测试人员设置完脚本运行8小时后，第二天总会发现虽然脚本运行正常，但是有一个节点上的Server没有相应。查看日志说日志没有任何报错，记录的最后一条总是前一天的半夜。因为半夜正好是做批处理的时候，一开始怀疑是否是这导致的宕机，但是停掉批处理程序后依旧发生这种现象（而且是在下班时刻发生），也就排除了这个可能。

下面是我的排错经过：

查看无法提供服务的app2的systemout.log日志，发现从昨天晚上5点09分后，没有新的日志输出。最后的日志为

[4/15/09 17:09:28:193 GMT+08:00] 00000953 IncidentStrea W com.ibm.ws.ffdc.IncidentStreamImpl write FFDC0013I: FFDC failed to write to incident stream file /was/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/ffdc/APP2_44ca44ca_09.04.15_17.09.28_0.txt, caught exception java.lang.NullPointerException

 

查看system.err文件，没有发现有价值的内容

于是查看ffdc目录下的17：09生成的日志，在APP2_7b2c7b2c_09.04.15_17.09.27_0.txt中发现有Stack Dump = javax.imageio.IIOException: Can’t create output stream!信息。

在APP2_2e542e54_09.04.15_17.09.27_1.txt中发现有Caused by: [SOAPException: faultCode=SOAP-ENV:Client; msg=Error opening socket: java.net.SocketException: Too many open files; targetException=java.lang.IllegalArgumentException: Error opening socket: java.net.SocketException: Too many open files]

 

于是使用ulimit –a命令查看AIX的limit参数

APP2:/was/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/ffdc#ulimit -a
time(seconds) unlimited
file(blocks) 2097151
data(kbytes) 131072
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 2097151
nofiles(descriptors) 2000

 

发现一个进程可以打开的最大文件数为2000.

用ps –ef | grep java命令找到app2的sid，然后用procfiles sid命令查看app2的进程现在打开了多少文件

APP2:/was/IBM/WebSphere/AppServer/profiles/AppSrv01/bin#procfiles 815304

815304 : /was/IBM/WebSphere/AppServer/java/bin/java -Declipse.security -Dwas.status.sock

Current rlimit: 2000 file descriptors

………………

1993: S_IFREG mode:0444 dev:10,15 ino:160745 uid:0 gid:0 rdev:0,0

O_RDONLY size:15694

1994: S_IFREG mode:0444 dev:10,15 ino:160745 uid:0 gid:0 rdev:0,0

O_RDONLY size:15694

1995: S_IFREG mode:0444 dev:10,15 ino:160745 uid:0 gid:0 rdev:0,0

O_RDONLY size:15694

1999: S_IFREG mode:0444 dev:10,15 ino:164300 uid:0 gid:0 rdev:0,0

O_RDONLY size:1042

打开文件数已经到达2000，于是app2无法创建新的systemout.log日志文件，也就无法再提供服务。

由此分析得AIX的nofiles参数对于websphere来说不够大（对于Hp-ux，安装前调整系统参数时就需要把maxfiles调整为8192，但是AIX内核是自调整，所以IBM安装要求上没有提到需要手动修改什么参数）特别是在压力测试时候，短时间内的积累可能会达到2000的限制，实际生产环境中也可能会遇到如此情况，当然集群中另外一台APP跑的好好的也挺让人奇怪。

接下来就是调整ulimit中的nofiles限制到4096，然后重启nodeagent，再由控制台重启app即可。当然也可以直接用命令重启app，但是因为nodeagent没有重启过，环境变量没有生效，下次在控制台中重启app后nofiles依旧会被限制在2000。

分类: Websphere系列, 排错 标签: , ,