Planetj 开源包读取压缩文件BUG分析过程

1. 第一弹，Planetj 开源包读取压缩文件BUG。

 

1. BUG描述：

 

在Tomcat 7 以上的服务器上运行，访问ODIN系统登录页面速度很慢。

     2. BUG定位过程（猜测与验证）：

 

＆是否是后端tomcat 转发到页面慢 ---->>> 经验证，首页面后端处理很少，参考URL访问日志进入与返回处理都正常。

 

＆推测是前端脚本在Chrome上运行过慢导致 ---->>> 在其他的浏览器上也一样显示出来很很慢，期间打开了Chrome查看首页面包含的文件内容，其中有一个md5.js 加载时间超过了 20s。

＆当时一个是下载的慢，还有一个是载入md5.js 时运行的慢 ---->>> 用排除法则，md5.js 在Tomcat 6中访问时，在同样浏览器中运行正常，查看了该文件确实有许多的位字节的操作，也没有到导致CPU负荷的程度，发现一个重要的点（ 与服务器上访问URL超时相同 ），据此可以确认是后端的BUG。

 

＆推测是读取文件慢，但是唯独读取JS类型文件慢呢？ ---->>> 把登录页面去掉JS文件的引用后，载入明显正常了，据此可知，定是服务上对JS类型的文件做了特殊处理，查看web.xml文件中的配置 CompressingFilter 的过滤器，对*.jsp、*.do、*.html、*.js、*.css 类型的文件的处理，进一步如果把这个过滤器配置去掉，访问也就正常了。

 

＆问题已经定位到由于 CompressingFilter 的过滤器导致，这个过滤器在不同的Tomcat 版本中为何表现的不一样呢？---->>> 通过Chrome 浏览器查看请求md5.js 文件的Response报文头分析:

 

 

而源文件的大小：说明 Response的头部的内容的长度为没有压缩前的长度，导致浏览器误以为文件流没有完全读取完毕，而实际上经过压缩后的流应该小于这个值的，直到服务器读取超时才断开连接。

 

＆BUG导致原因算是定位明白，怎么处理这个BUG呢？---->>> 一种是规避这个BUG，去掉CompressingFilter 过滤器的配置，但是对大型的文件会降低了服务器的性能。如果要修改这个BUG，因为这个过滤器是开源包，必将修改这个版本的源码，重新编译、打包。

 

＆怎样将BUG定位到代码级别呢？---->>> 既然是Response的长度设置问题，首先找到文件下载时，文件长度设置的代码位置。通过debug的Tomcat 8源代码可知，处理请求的类是 DefaultServlet 再输出流时，如果是按压缩流输出时，应该不需要设置Response的 Header 设置内容属性的长度 Content-Length 的值。实际中查看源码 Planetj 中的 CompressingHttpServletResponse 在压缩时，不会设置这个属性值的，

。那么，Content-Length 这个属性的值是在哪里设置的呢？？

 

＆定位到设置 Content-Length 的调用入口？---->>> 经Tomcat8源代码分析，DefaultServlet 在输出内容时，

会调用  方法，而该方法是 Servlet 3.1 规范新加的，而Planetj 是基于Servlet 3.1之前的版本，因此 CompressingHttpServletResponse 类中只定义了

 ， 所以当调用 setContentLengthLong 时，有调用到 Response 中对应的方法，因此，在类 Http11Processor 输出头部信息时会加上 Content-Length 的长度值，本来压缩的Response 的头部信息是不需要这个属性的。

＆正常的Response 报文：

＆SERVLET 3.1的定义：

     3. BUG处理：

在 CompressingHttpServletResponse 重载方法 setContentLengthLong 使其正常调用，定义如下：

正常载入md5.js 文件的信息，如下所示：