[以下轉貼自樂樂的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回美帝國改代碼打包重發布了，不知道現在情況怎樣。