随笔 - 42  文章 - 71  trackbacks - 0
<2009年1月>
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567

常用链接

留言簿

随笔档案

文章分类

文章档案

搜索

  •  

最新评论

阅读排行榜

评论排行榜

[以下转贴自乐乐的Space,乐乐,不要跟我要钱啊~]

上周在济南某客户现场为jolt的使用做了一次troubleshooting,总结如下:

  1. 如果不使用wls,同样可以使用jolt提供的pool功能,而这又分为两种:一种是基于web容器的servlet jolt pool,另一种则是普通java客户端的jolt pool。前者在$TUXDIR/udataobj/jolt/examples/servlet/simpapp下有示例,后者则未提供,所以我自己写了个例子
  2. 如果不使用jolt产品自带的pool,也可以自己实现。套路为:创建Jolt Session > 基于此session构建JoltRemoteService对象并发起tuxedo调用 > 释放jolt session。这里有个要点就是在使用session前需要用session.isAlive()来判断当前session是否可用,因为JSL的-T参数及防火墙对idle连接的干扰都可能导致已有的session是无效的。
  3. 创建JoltRemoteSession时一定记得为三个超时属性(IDLETIMEOUT/RECVTIMEOUT/SENDTIMEOUT)进行显式的设置。idle超时和tuxedo的JSL -T属性对应,该设置将保证session.isAlive()返回正确的布尔值。RECV超时则控制client端自发起call至收到tuxedo return这一过程的预期时常。send用处不大,不表。
  4. tuxedo侧在ubb里为相应的service配置了SVCTIMEOUT,所以service执行超时后会收到SIGKILL而被终止,这样一来,客户端的call会收到TPESVCERR错,对应的异常为bea.jolt.ServiceException。客户端需要对此异常进行处理,此外,客户端捕获此异常的时间点应当和ulog中该server被kill的时间点对应。
  5. 在客户端,时不时会发现由于达到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 阅读(1814) 评论(0)  编辑  收藏

只有注册用户登录后才能发表评论。


网站导航: