今天碰到個問題,xfire客戶端呼叫遠端的webservice伺服器，在異常日誌stdout中打了些read timeout 後，從jconsole觀察到resin的執行緒數量直線上公升，直到把所有執行緒都佔滿，後來看到是xfire的xfireclientfactorybean的
getclient方法阻塞了，在網上檢視了各種配置，均無效。後來把那台webservice伺服器放到公司內部網路就沒有問題了
經驗教訓：
webservice超時問題，最關鍵的是要解決網路問題
在解決此問題後，回頭再仔細分析成因。
首先在自己的測試環境中模擬這種連線超時的情況
1.把webservice的wsdl位址配置成乙個遠端的無法訪問的ip位址，提供乙個url來模擬呼叫webservice客戶端
2.啟動web伺服器，用jconsole監控執行緒狀況
3.用apache的ab工具，併發100個執行緒，請求第1步中的url
4.分析執行緒狀態，找到上100個阻塞的執行緒，再找到擁有阻塞物件的執行緒，發現是阻塞在xfire的resovler物件的方法裡
最終阻塞是在url.openstream方法裡，xfire呼叫webservice會先驗證wsdl的有效性，用的就是new url(wsdl).openstream方法，這時網路不通，就會阻塞在此。這個url.openstream方法的超時時間並不能在xfire的引數中進行配置，是預設值。可以把wsdl檔案配置在本地，會減少這種情況發生的可能性。
5.在呼叫webservice時的引數，可以參考以下配置
5000
5000
200300
true
true
以上配置中各屬性的含義需要明確另外，糾正乙個網上乙個錯誤的概念，urlconnection的預設超時時間並不是0，0代表永不超時，只是代表沒有設定而已，作業系統會提供乙個預設的socket超時時間,我在windows的xp上測試的時間約為20秒，測試方法很簡單，
url url = new url("");
long now = system.currentmills();
trycatch(exception e){
system.out.println(system.currentmills()-now);
也可以用socket做實驗效果一樣。
XFire客戶端開發
引入 xfire相關的類庫 1.使用wsdl生成靜態客戶端 訪問任意語言編寫的web service 2.使用介面生成靜態客戶端 必須拿到服務端的介面class檔案 遠端 工廠 xfireproxyfactory factory new xfireproxyfactory 建立服務模型 servic...
webservice客戶端超時
使用axis2生成webserice客戶端時，在引用的jar包axis2 kernel下的org.apache.axis2.client.options類中預設設定通訊超時時間為30s，jar包原始碼如下，可以看到預設時間為final常量 package org.apache.axis2.clien...
XFire客戶端流程分析及案例
下面是xfire客戶端呼叫的流程分析圖，本文後續部分將圍繞該圖展開。服務模型是xfire中非常重要的概念之一，包含了服務的介面資訊 操作資訊 binding資訊等諸多服務呼叫過程中需要的資訊。因此在進行服務呼叫之前首先要建立服務模型。建立服務模型的工作是由服務工廠servicefactory完成的，...