webservice Connection timed out

webservice Connection timed out，當發生webservice的鏈接超時錯誤時，我想原因無非就是webclient到webservice之間的鏈接通路發生了異常，那麼該如何解決呢？

一、錯誤日志

為了能夠對號入座，我們先來看看錯誤日志：

ERROR 2015-05-28 10:40:06,482 com.honzh.socket.util.ExchangeUtil: ; nested exception is: 
java.net.ConnectException: Connection timed out: connect
AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
 faultSubcode: 
 faultString: java.net.ConnectException: Connection timed out: connect
 faultActor: 
 faultNode: 
 faultDetail: 
{http://xml.apache.org/axis/}stackTrace:java.net.ConnectException: Connection timed out: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)

從錯誤日志看來，代碼部分應該屬於正常，看不出有什麼錯誤，其他方面，暫時也看不出什麼門道。這讓我想起了從攜程故障回顧在線服務的黑天鵝，裡面關於程序穩定百分比對於服務器中斷時間的影響：

99.9%，服務中斷時間：525.6分鐘/年
99.99%，服務中斷時間：52.56分鐘/年
99.999%，服務中斷時間：5.256分鐘/年

也就是說明，程序總會在意想不到的情況下發生異常，發生異常時，最重要的就是保持好心態，找出原因。

二、解決之道

①、先來看看其他的地方可以訪問這個webservice不能？

換了一台webclient來訪問該webservice，發現正常，看來不是webservice服務器的問題，問題可能發生在上述錯誤的那台機器上。

②、ping雙方ip

我就不截圖了，發現雙方心跳包正常，那麼再來看看端口有沒有被占用。

③、netstat -nao

發現webservice鏈接的端口也正常，沒有被其他端口占用。

④、telenet一下ip和端口

發現連接失敗，這肯定是有問題的，那怎麼解決呢？請教了一下專業人士，說可以修改一下服務器的跳躍點。

⑤、跳躍點

關於跳躍點，顯然我不太清楚是啥意思，就先問度娘：

躍點：即路由。一個路由為一個躍點。傳輸過程中需要經過多個網絡，每個被經過的網絡設備點（有能力路由的）叫做一個躍點，地址就是它的ip。躍點數是經過了多少個躍點的累加器，為了防止無用的數據包在網上流散。 為路由指定所需躍點數的整數值（范圍是 1 ~ 9999），它用來在路由表裡的多個路由中選擇與轉發包中的目標地址最為匹配的路由。所選的路由具有最少的躍點數。躍點數能夠反映躍點的數量、路徑的速度、路徑可靠性、路徑吞吐量以及管理屬性。

好吧，太專業，還是不懂，不過可以嘗試著試一試：

修改了跳躍點後，再來連接webservice，發現連接通了。當然了，這只是一種解決辦法，還有另外一種。

⑥、修改webservice的默認端口號

比如說將原來的8080改為8180，發現webservice連接也OK，這當然是建立在沒有修改跳躍點的基礎上。

tips：一般情況下，我們都不會使用默認端口號，容易受到攻擊，也容易發生異常。