[以下转贴自乐乐的Space,乐乐,不要跟我要钱啊~]
上周在济南某客户现场为jolt的使用做了一次troubleshooting,总结如下:
- 如果不使用wls,同样可以使用jolt提供的pool功能,而这又分为两种:一种是基于web容器的servlet jolt pool,另一种则是普通java客户端的jolt pool。前者在$TUXDIR/udataobj/jolt/examples/servlet/simpapp下有示例,后者则未提供,所以我自己写了个例子。
- 如果不使用jolt产品自带的pool,也可以自己实现。套路为:创建Jolt Session > 基于此session构建JoltRemoteService对象并发起tuxedo调用 > 释放jolt session。这里有个要点就是在使用session前需要用session.isAlive()来判断当前session是否可用,因为JSL的-T参数及防火墙对idle连接的干扰都可能导致已有的session是无效的。
- 创建JoltRemoteSession时一定记得为三个超时属性(IDLETIMEOUT/RECVTIMEOUT/SENDTIMEOUT)进行显式的设置。idle超时和tuxedo的JSL -T属性对应,该设置将保证session.isAlive()返回正确的布尔值。RECV超时则控制client端自发起call至收到tuxedo return这一过程的预期时常。send用处不大,不表。
- tuxedo侧在ubb里为相应的service配置了SVCTIMEOUT,所以service执行超时后会收到SIGKILL而被终止,这样一来,客户端的call会收到TPESVCERR错,对应的异常为bea.jolt.ServiceException。客户端需要对此异常进行处理,此外,客户端捕获此异常的时间点应当和ulog中该server被kill的时间点对应。
- 在客户端,时不时会发现由于达到RECVTIMEOUT而导致的客户端接收超时。客户的疑问是:当前RECVTIMEOUT设置为25s,而ubb中相应SVCTIMEOUT设置为10s且scanunit为默认的10s,所以理论上不应发生25s的客户端RECVTIMEOUT超时。庹达人提出了一种怀疑,即client端请求抵达tuxedo侧时,server出现排队情况,请求未被及时处理,这个排队时长决定了20s以外的时间差。对于此,建议客户使用MSSQ,并监控pq的情况。
************* 插曲 *************
昨天写到第4条的时候被派遣出去了。是wls92的问题,检查后发现应用synchronized使用存在一些问题,导致并发稍大时wls挂起。应用是老外写的,一起开会后丫就vpn回美帝国改代码打包重发布了,不知道现在情况怎样。
posted on 2009-01-07 15:08
YODA 阅读(1842)
评论(0) 编辑 收藏