JDK1.8.0.161版本bug定位

1. 有个老系统有使用到soap接口，采用CXF结合接口文件wsdl自动生成的接口开发的，突然在3月2日（后续日志定位才发现真正故障的时间）无法正常工作，但是实际发现时间已经到了3月6日了，直接查看日志文件，报错“组装saop报文头异常:Entity References are not allowed in SOAP documents”，想到看看是不是代码做了什么改动，进svn版本管理 工具 对比，没有改动，最近一次部署是在3月5日上午，3月2日周六突然就故障了，属于突发性异常，感觉可以排除自身的问题，然后去咨询服务端系统，对方说也没有任何改动，现在才接手，不可能进行新的开发。但是接口一直在日志中打印错误，对比svn提交记录，发现确实没人改动代码，难道是对方动了代码？抱着这种心态总觉得是服务端异常了。

2. 有了这个排除自己代码改动造成异常的前提后，始终觉得是服务端异常了，然后通过抓包对比正常接口、异常接口，SoapUI发送，重现错误返回值等一系列对比，3月6、7日没有任何结果，唯一发现就是报错的接口没有soap请求没有head信息，只有UTF-8的字符集和body，这种结构就有些奇怪了，难道是鉴权账号被锁？继续用soapUI测试这个账号，其他接口跑起来正常，修改了一条数据发证success，更加郁闷了，怎么可能head平白无故丢失呢？

3. 继续啃这个问题，因为有数据堵住了，慢慢积压越来越多，这样下去迟早会造成更大的失误。问题还是要继续解决，只好重新打包个测试包，去测试环境对接soap服务端，下个订单，查看日志和抓包，查看接口推送的请求，测试环境验证正常，说明代码OK，抓包查看xml报文，head和body都在。6、7日的对比把报错的信息复制到百度看看有没查询到类似的案例，结果都是乱七八糟的一堆东西，没什么价值。

4. 6、7号1天半没找到问题，但是又不可以继续拖了，试试google呗，一下眼前一样，第一条查询就是openJDK的bug库，一直没怀疑jdk的bug，始终认为它是正常的，赶快找到jdk bug库，把关键字放进去一查询，查到结果有个bug单，心里一喜，终于找到问题原因了。啃了2天半了，终于找到问题的原因了，https://bugs.openjdk.java.net/browse/JDK-8196491，https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8196491，https://stackoverflow.com/questions/48603942/latest-open-jdk-8-jaxb-library-fails-to-unmarshal-objects-with-properties-that-c

5. 这里吐槽下，垃圾百度，以前还可以筛选一些有用的信息，这次白白浪费2天的时间，没有价值的信息一堆，就放弃网上找案例了。 google里面可以找到stackflow和openjdk的链接，已经确认jdk1.8.0版本的bug，2018年01月份暴露该bug，2018年04月份修复，修复版本是1.8.0.192。

6. 立马下载最新202 update版本，部署环境，重新，偶然没有出现相同的错了，然后一看时间，已经是3月8日21:30了，继续观察下，确认正常，问题得以修复。估算堵住的数据，预计还需要36小时才可以处理完，周末时间刚好。这下周末可以轻松下，不用跑来继续啃问题了。

附上错误信息截图：