今天碰到个问题,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时的参数,可以参考以下配置
<property name="properties"> <props> <prop key="http.connection.manager.timeout">5000</prop> <prop key="http.connection.timeout">5000</prop> <prop key="http.timeout">5000</prop> <prop key="max.connections.per.host">200</prop> <prop key="max.total.connections">300</prop> <prop key="disable-keep-alive">true</prop> <prop key="disable.expect-continue">true</prop> </props> </property>
以上配置中各属性的含义需要明确
另外,纠正一个网上一个错误的概念,URLConnection的默认超时时间并不是0,0代表永不超时,只是代表没有设置而已,操作系统会提供一个默认的socket超时时间,我在windows的xp上测试的时间约为20秒,测试方法很简单,
URL url = new URL("http://10.1.1.1");
long now = System.currentMills();
try{
url.openStream();
}catch(Exception e){
System.out.println(System.currentMills()-now);
}
也可以用socket做实验效果一样。