200分求XFire异常，很急。顶着有份（可追加）

Question

Unexpected close tag </body>; expected </HR>
服务器报这个异常，在XFire验证Hanlder部分。
我查了网上说：服务端缺少xalan.jar包
我项目里面是有这个包的xalan-2.5.1.jar
为了解决这个异常，我下了最新的xalan-2.7.1，跟踪日志测试还是会出这个异常。
而且每次到出现这个异常的时候，后面所有的验证都死掉了。。
所有请求都挂在security验证部分。
求解！～

Answer 1

以前貌似有碰到过这个问题，如果是报这个错
Unexpected close tag </body>; expected </HR>
貌似是很明确了，抓包验证一下是不是请求消息真的如异常描述如果是真的，就更容易排查原因了

Answer 2

虽然我后来都用的axis，但也不能说xfire一定会出这类特定问题，但也不能百分百保证，能不能换cxf再测试呢？
我指的抓包就是抓客户端发给服务端的请求消息包，看它的请求消息内容与格式，不过看了你的描述，请求体中如果带有xml格式节点，就有会导致破坏协议体格式的可能，毕竟1～2小时之内发的包与之前的都没变过吗？或者变化的是什么

Answer 3

cxf？现在平台等着上线，很多服务商接入进来 发现的这个问题。
在出现这个挂起状态的时候，我是把该时候的wsdl下载看了。这个XML文件和正常的时候完全没区别

Answer 4

不是wsdl，wsdl不会变的，是请求消息，使用webservice不是要向服务端发请求消息来交互的嘛
说具体点比如用wireshark持续抓包，不过可能定位这个包都有点麻烦～总之找不到原因的话也总是免不了要多试吧

Answer 5

有说这个问题是：
This was a transient error. If you retry, everything should be fine.看来有可能是xfire的固有问题，服务器有这个错误的详细堆栈日志吗

Answer 6

没有。我发现可能不是XFire的问题

Answer 7

我发现这个异常不是XFire造成的。经过长时间的分析，发现当客户端发起请求后，会到ws security验证的。
我把可能会出现错误的地方都写了日志，到服务器上面跟踪日志信息发现。。
当执行到memcached缓存部分的时候就挂在那里了。貌似是线程池没有连接，在等待。
后来发现在某个时候确实有这个问题。
所以个人觉得，当线程池没有线程了。memcached_client会在那里等线程释放，这个时候ws 超时了。所以返回给客户端的xml文件没有组织完全，才报这个错误。
当然这个想法还没有最后验证，现在还在生产环境中测试。

Answer 8

Unexpected close tag </body>; expected </HR>
服务器报这个异常按理这个异常应该是服务器端接收到客户端发来的消息验证为非法后报的，而不是客户端收到，这不是服务器端报的嘛看到网上有个bug提交页有提到这个bug，不过是06年的，涉及联网不联网之类，jetty和tomcat都表现各异如果说是线程池没有连接，那就意味着是短暂错误，这个很好验证，等释放后看看能否回复正常，能回复正常，一定程度上也证明了这点

Answer 9

恩，是的，只不过开始的时候没有想到是cache池造成的。因为客户端每次连接的返回都会报这个异常，所以把关注力都放在XFire上了。

Answer 10

个人理解如果是组织输出，</body>肯定比</HR>后，不可能说</HR>没等到，</body>就先出现了。感觉像是线程同步相关的逻辑bug，感觉而已。

Answer 11

楼上说感觉是线程同步的逻辑bug，可否说的再明白点。

Answer 12

我猜的，帮你探探思路。在某种特殊情况下，验证器内部因为多线程bug，无法回到正常状态，（也就是俗话说 卡死了）
后面所有的验证貌似都可以通行，但其实只能得到这个错误状态下的错误输出结果。

Answer 13

那能不能分享下你所说的多线程bug的经验？或者如果避免或者解决方案？