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：一般情况下，我们都不会使用默认端口号，容易受到攻击，也容易发生异常。

笑对现实的无奈，不能后退的时候，不再傍徨的时候，永远向前　路一直都在──陈奕迅《路一直都在》
本文出自:【沉默王二的博客】