[以下轉(zhuǎn)貼自樂樂的Space，樂樂，不要跟我要錢啊～]

上周在濟(jì)南某客戶現(xiàn)場(chǎng)為jolt的使用做了一次troubleshooting，總結(jié)如下：

1. 如果不使用wls，同樣可以使用jolt提供的pool功能，而這又分為兩種：一種是基于web容器的servlet jolt pool，另一種則是普通java客戶端的jolt pool。前者在$TUXDIR/udataobj/jolt/examples/servlet/simpapp下有示例，后者則未提供，所以我自己寫了個(gè)例子。
2. 如果不使用jolt產(chǎn)品自帶的pool，也可以自己實(shí)現(xiàn)。套路為：創(chuàng)建Jolt Session > 基于此session構(gòu)建JoltRemoteService對(duì)象并發(fā)起tuxedo調(diào)用 > 釋放jolt session。這里有個(gè)要點(diǎn)就是在使用session前需要用session.isAlive()來(lái)判斷當(dāng)前session是否可用，因?yàn)镴SL的-T參數(shù)及防火墻對(duì)idle連接的干擾都可能導(dǎo)致已有的session是無(wú)效的。
3. 創(chuàng)建JoltRemoteSession時(shí)一定記得為三個(gè)超時(shí)屬性（IDLETIMEOUT/RECVTIMEOUT/SENDTIMEOUT）進(jìn)行顯式的設(shè)置。idle超時(shí)和tuxedo的JSL -T屬性對(duì)應(yīng)，該設(shè)置將保證session.isAlive()返回正確的布爾值。RECV超時(shí)則控制client端自發(fā)起call至收到tuxedo return這一過(guò)程的預(yù)期時(shí)常。send用處不大，不表。
4. tuxedo側(cè)在ubb里為相應(yīng)的service配置了SVCTIMEOUT，所以service執(zhí)行超時(shí)后會(huì)收到SIGKILL而被終止，這樣一來(lái)，客戶端的call會(huì)收到TPESVCERR錯(cuò)，對(duì)應(yīng)的異常為bea.jolt.ServiceException。客戶端需要對(duì)此異常進(jìn)行處理，此外，客戶端捕獲此異常的時(shí)間點(diǎn)應(yīng)當(dāng)和ulog中該server被kill的時(shí)間點(diǎn)對(duì)應(yīng)。
5. 在客戶端，時(shí)不時(shí)會(huì)發(fā)現(xiàn)由于達(dá)到RECVTIMEOUT而導(dǎo)致的客戶端接收超時(shí)。客戶的疑問是：當(dāng)前RECVTIMEOUT設(shè)置為25s，而ubb中相應(yīng)SVCTIMEOUT設(shè)置為10s且scanunit為默認(rèn)的10s，所以理論上不應(yīng)發(fā)生25s的客戶端RECVTIMEOUT超時(shí)。庹達(dá)人提出了一種懷疑，即client端請(qǐng)求抵達(dá)tuxedo側(cè)時(shí)，server出現(xiàn)排隊(duì)情況，請(qǐng)求未被及時(shí)處理，這個(gè)排隊(duì)時(shí)長(zhǎng)決定了20s以外的時(shí)間差。對(duì)于此，建議客戶使用MSSQ，并監(jiān)控pq的情況。

************* 插曲 *************

昨天寫到第4條的時(shí)候被派遣出去了。是wls92的問題，檢查后發(fā)現(xiàn)應(yīng)用synchronized使用存在一些問題，導(dǎo)致并發(fā)稍大時(shí)wls掛起。應(yīng)用是老外寫的，一起開會(huì)后丫就vpn回美帝國(guó)改代碼打包重發(fā)布了，不知道現(xiàn)在情況怎樣。