[以下转贴自乐乐的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回美帝国改代码打包重发布了，不知道现在情况怎样。