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)

从错误日志看来，代码部分应该属于正常，看不出有什么错误，其它方面。临时也看不出什么门道。这让我想起了从携程故障回想在线服务的黑天鹅。里面关于程序稳定百分比对于server中断时间的影响：

99.9%。服务中断时间：525.6分钟/年

99.99%，服务中断时间：52.56分钟/年

99.999%，服务中断时间：5.256分钟/年

也就是说明，程序总会在意想不到的情况下发生异常。发生异常时，最重要的就是保持好心态。找出原因。

二、解决之道

①、先来看看其它的地方能够訪问这个webservice不能？

换了一台webclient来訪问该webservice。发现正常。看来不是webserviceserver的问题，问题可能发生在上述错误的那台机器上。

②、ping两方ip

我就不截图了，发现两方心跳包正常，那么再来看看port有没有被占用。

③、netstat -nao

发现webservice链接的port也正常，没有被其它port占用。

④、telenet一下ip和port

发现连接失败，这肯定是有问题的。那怎么解决呢？请教了一下专业人士，说能够改动一下server的跳跃点。

⑤、跳跃点

关于跳跃点，显然我不太清楚是啥意思。就先问度娘：

跃点：即路由。一个路由为一个跃点。传输过程中须要经过多个网络，每一个被经过的网络设备点（有能力路由的）叫做一个跃点，地址就是它的ip。跃点数是经过了多少个跃点的累加器，为了防止没用的数据包在网上流散。为路由指定所需跃点数的整数值（范围是 1 ~ 9999），它用来在路由表里的多个路由中选择与转发包中的目标地址最为匹配的路由。所选的路由具有最少的跃点数。跃点数能够反映跃点的数量、路径的速度、路径可靠性、路径吞吐量以及管理属性。

好吧。太专业。还是不懂，只是能够尝试着试一试：

改动了跳跃点后，再来连接webservice，发现连接通了。当然了，这仅仅是一种解决的方法。还有第二种。

⑥、改动webservice的默认port号

比方说将原来的8080改为8180，发现webservice连接也OK，这当然是建立在没有改动跳跃点的基础上。

tips：普通情况下，我们都不会使用默认port号，easy受到攻击，也easy发生异常。

笑对现实的无奈，不能后退的时候，不再傍徨的时候。永远向前　路一直都在──陈奕迅《路一直都在》

本文出自:【沉默王二的博客】