WAS系统垮了,客户疯了,又有事情做了!!!
分析了日志文件
Native_stderr.log
Native_stdiut.log
Server1.pid
Startserver.log
Stopserver.log
Systemerr.log
Systemout.log
PS: 由于对log文件的收集没有加 -trace参数,所以得到的信息比较有限,希望以后兄弟们能够提交日志文件的时候能够记得加这个参数。
虽然比较有限,但是还是可以看到一些端倪:
通过分析SystemOut.log日志文件,可以得出以下信息:
************ Start Display Current Environment ************
WebSphere Platform 5.0 [BASE 5.0.1 ptf1M0313.03] running with process name oasvr/oasvr/server1 and process id 4460
Host Operating System is Windows 2000, version 5.0
Java version = J2RE 1.3.1 IBM Windows 32 build cn131-20030329 (JIT enabled: jitc), Java Compiler = jitc, Java VM name = Classic VM
was.install.root = d:/ibm/WebSphere/AppServer
user.install.root = d:/ibm/WebSphere/AppServer
Java Home = d:/ibm/WebSphere/AppServer/java/jre
ws.ext.dirs = d:/ibm/WebSphere/AppServer/java/lib;d:/ibm/WebSphere/AppServer/classes;d:/ibm/WebSphere/AppServer/classes;d:/ibm/WebSphere/AppServer/lib;d:/ibm/WebSphere/AppServer/lib/ext;d:/ibm/WebSphere/AppServer/web/help;d:/ibm/WebSphere/AppServer/deploytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime
Classpath = d:/ibm/WebSphere/AppServer/properties;d:/ibm/WebSphere/AppServer/properties;d:/ibm/WebSphere/AppServer/lib/bootstrap.jar;d:/ibm/WebSphere/AppServer/lib/j2ee.jar;d:/ibm/WebSphere/AppServer/lib/lmproxy.jar
Java Library path = d:/ibm/WebSphere/AppServer/java/bin;.;C:/WINNT/system32;C:/WINNT;d:/ibm/WebSphere/AppServer/bin;d:/ibm/WebSphere/AppServer/java/bin;d:/ibm/WebSphere/AppServer/java/jre/bin;D:/ibm/WebSphere MQ/Java/lib;d:/oracle/ora92/bin;C:/Program Files/Oracle/jre/1.3.1/bin;C:/Program Files/Oracle/jre/1.1.8/bin;D:/j2sdk1.4.2_09/bin;C:/WINNT/system32;C:/WINNT;C:/WINNT/System32/Wbem;D:/ibm/WebSphere MQ/bin;D:/ibm/WebSphere MQ/WEMPS/bin;C:/Program Files/IDM Computer Solutions/UltraEdit-32;D:/ibm/WebSphere MQ/bin;D:/ibm/WebSphere MQ/java/bin;D:/ibm/WebSphere MQ/WEMPS/bin
WebSphere Application Server Base Version 5.0.1,平台版本0313.03,
该版本对应JDK:1.3.1.07(SR4)
OASVR可以推测其运行环境是一个J2EE的OA平台,just in time 已经打开
系统环境变量中使用了WebSphere MQ,根据路径可以判断不是WAS自带message,因此对应MQ版本应该为CSD07,从路径中可以看到使用了2个Oracle9iR2实例,一个对应的JRE:1.1.8;一个对应的JRE:1.3.1.应用部署是在jdk1.4.2.09。
另外报错误:
[07-4-19 9:56:33:328 CST]
6130d48d SessionFactor W net.sf.hibernate.impl.SessionFactoryObjectFactory Could not bind factory to JNDI
[07-4-19 9:56:33:344 CST]
6130d48d SessionFactor W net.sf.hibernate.impl.SessionFactoryObjectFactory TRAS0014I:
下列异常已记录
javax.naming.OperationNotSupportedException: The operation on the context "java:env" cannot be completed. All contexts under java:comp/env are environment contexts and are read-only.
[07-4-19 9:56:34:422 CST]
6130d48d SharedPool I J2CA0086W:
在本地事务包含边界中使用的资源
jdbc/ylrun
的可分享连接
[07-4-19 9:56:34:906 CST]
6130d48d WSRdbDataSour u Database version is Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.7.0 - Production
[07-4-19 9:56:34:906 CST] 6130d48d
WSRdbDataSour u JDBC Driver version is 9.2.0.1.0
信息:WAS
数据源版本:Oracle 9.2.0.7.0 64bit
采用了数据挖掘组件,其中Jserver
版本9.2.0.7.0
JDBC
驱动9.2.0.1.0
(目前看不到是type2
还是type4
驱动)
错误:不能绑定JNDI
解决办法:
可以通过log看到应用中使用了hibernate数据持久化技术、结合Startserver.log、Stopserver.log、Systemerr.log、Systemout.log此错误是配置文件的问题,如果hibernate配置文件有session_factory_name这个变量,<session-factory name="foo"> 会试图将一个SessionFactory实例以foo为名bind到jndi上,而有的application container不支持jndi绑定。把这个变量去掉即可。把引用代码也要修改:
大致改成这样:
SessionFactory sf = new Configuration().configure()
.buildSessionFactory();
Session session = sf.openSession();
Transaction tx = session.beginTransaction();
WAS确实可以不需要自己写程序来进行绑定,也可以由Hibernate自己在运行期进行动态绑定。但是如果使用Hibernate自己的运行期绑定的话,有一个悖论,就是只有在Hibernate被初次调用进行初始化的时候,才会将SessionFactory的实例绑定到JNDI上去,那么意味着,在首次调用Hibernate之前,JNDI上是没有SessionFactory实例的,所以你必须在所有的其它程序通过JNDI获得SessionFactory实例之前,运行某个程序对Hibernate进行初始化,把SessionFactory实例绑定到JNDI上。如果是纯Servlet/JSP应用的话,可以配置一个load-up=1的servlet进行Hibernate的初始化,如果是混合EJB,Servlet/JSP的应用,就无法保证在程序被调用前对Hibernate进行初始化,因此对于WebSphere来说,最保险的解决办法就是建立一个StartUp类,确保WAS一启动,就对Hibernate进行初始化。
错误:java:env
命名异常,报错误TRAS0014I
java.lang.ClassNotFoundException: cn.com.info21.power.runlog.action.TestAction
解决办法:
查看class情况,该错误可能由以上错误引起。
分析日志system.out_07.04.19_09.51.59.log
[07-4-19 9:29:49:422 CST]
7ac9d17d Helpers W NMSV0610I:
从
javax.naming.Context
实现中抛出
NamingException
。详细信息如下:
上下文实现:
com.ibm.ws.naming.java.javaURLContext
上下文方法:
createSubcontext(String)
上下文名称:
java:comp/env
目标名称:
hibernate
其它数据:
异常堆栈跟踪:
javax.naming.OperationNotSupportedException: The operation on the context "java:env" cannot be completed
错误NMSV0610I
依然是env的原因,如果报该错误号,但上下文com.ibm.ws.naming.jndicos.CNContextImpl 的话,那么需要注意J2C问题了。一般这样的问题是应用是EJB 1.1规范进行开发的,而部署到WAS5上面的时候,连接遵从J2C的数据源就会出现这样的错误,解决办法看我以前写的一个EJB移植问题文档。
[07-4-18 9:19:57:031 CST] 1f7a20d0 SystemErr R java.net.SocketException: Connection reset by peer: socket closed
[07-4-19 9:32:23:328 CST] 7e02d14f WebGroup E SRVE0026E:
[
Servlet
错误]-[
Connection reset by peer: socket write error
]:
java.net.SocketException: Connection reset by peer: socket write error
错误:SRVE0026E
,servlet
错误,Socket
写入错误
类似这种错误,我以前解决了一个更加怪异的。WAS5+SQLSERVER2000SP4采用ODBC数据源连接时,不出现这种错误,而采用JDBC则出现这种错误.解决办法:不使用SP4,使用SQL SERVER SP3A即可解决。
SRVE0026E错误,请升级WAS补丁到5.1即可解决数据库访问并发释放连接、socket写入错误等问题
错误:在本地事务边界中使用资源连接分享,报错误J2CA0086W
解决办法:
系统报告“J2CA0086W”是为了警告用户,应用程序正在一个本地交易(而不是全局交易)中使用共享连结,例如按照如下的方式使用了数据库的连接:
get con1; //建立一个新的连接con1
use con1; //使用con1
get con2; // 一个新的连接con2被建立。
// 再此处我们不能使用con1,因为它还没有被关闭
use con2;
close con1;
close con2;
解决这个问题的方法是打补丁PQ80044,打完这个补丁以后,“J2CA0086W”的警告将不会对于每一次连接都在日志中产生,而是对于每一个连接池产生一次。这个补丁已经被添加到WAS fix 5.0.2.3中,所以,也可以通过打补丁包WAS fix 5.0.2.3解决该问题。
注释:我的思路:
1、 由于配置的是Oracle JDBC Thin Driver,所以只能开一个连接,启动一个事务,关闭事务.但是由于应用中统计等功能比较多,出现打开一个连接,启动一个事务,又打开一个连接(报错),关闭事务的情况,所以想把JDBC改成Oracle JDBC Thin Driver (XA)可以实现打开一个连接,启动事务,又打开一个连接,启动事务,关闭事务,关闭事务的机制.
2、 WAS5默认是2步事务提交、也就是在insert以后需要COMMIT才能提交
3、 还有就是在组装时,注意下要配置资源引用(名称jdbc/cceaoa3ds类型javax.sql.DataSource认证container,IBM扩展中的隔离级别:可提交事务读).Oracle JDBC Thin Driver (XA) 是用作分布式事务的,对于这个CASE,由于都部署在一台机器上,用Oracle JDBC Thin Driver 即可
4、 websphere 5.x 对事物管理有个 bug,如果用 struts 需要在 action 与 jsp 之间 close transaction.