一次由Tomcat重新加载引发的血案

引言: Tomcat是目前开发中使用非常广泛的Web服务器,其提供了很多优秀和简便易用的功能。我们这里的血案就是由于在部署过程中,不慎而引发的....

1. 问题的出现

    在我们的系统后台每日定义会触发一些任务操作,进行一些数据的处理和更新,从上线到现在已经正常运行了将近3个多月了。忽然某一天,发现其数据不对,大量的数据都是被执行了2次某个定时任务A造成的。 查询日志,的确是执行了2次。但是之前为什么是正常的呢?诡异诡异....

    环境: Tomcat 6.0.x

2.  血案的发生

   由于在生产系统中,数据出现了问题,这个是一个非常严重的事情。于是首先把这个定时任务A先停掉,清理数据。由于数据量比较大,所以就有了焦头烂额的几天修正系统数据的过程。

3.  问题分析

    3.1  任务A本身有问题吗?

          之前都是正常运行的, 只在最近几天才发生问题。而且基于日志分析,其数据操作是正确的,问题是操作了2遍。

    3.2  任务A实现分析

          首先怀疑其实现的代码上是否有问题? 经过分析其是基于Quartz来实现定时任务的,Quartz是老牌的定时框架,不会出现问题。 是否是我们自己使用的方式问题,并只在特定情况下才会出现问题呢? 经过代码的排查分析,没有问题。

     3.3  代码变更记录分析

         是否是某个同事无意之前做的什么修改造成的呢? 经过针对代码变更记录和上线记录的分析,排除这个可能。

4.  系统日志分析

     在排除了这个任务A自身问题之后,将目光转移到了环境本身。  部署环境是Tomcat6.  下载了Tomcat日志文件进行分析,逐渐找到了某些蛛丝马迹,从而剥丝抽茧般的发现了问题的原因。

     在系统日志中,发现了若干在应用部署过程中的错误信息,这个引起了我的怀疑。是否是由于在部署中的错误造成的呢?

     经过排查,确定是部署不慎造成的,而且是由于Tomcat本身的Reloadable特性造成的问题。

     

 5.  问题场景的还原

     1.  某位同事由于在修改某个问题,只修改了某几个Class文件,故其将编译后的class文件在服务器上直接进行了替换。

      2.   由于Tomcat本身设置了Reloadable的属性,故Tomcat在检测到class文件发生变化之后,对WebApp的应用进行了重新加载:先卸载,再重新加载。

      3.   在卸载的过程中,程序出错,卸载失败,原来的应用没有卸载成功,保留在Tomcat的缓存之中。

     

     4.   虽然卸载失败,Tomcat继续加载新的WebApp应用。这里请注意: 新加载的WebApp应用在项目名称之后加了一个2,比如原来的项目名称是AAA, 新的项目名称就是AAA2。 重新定义了一个项目名称哦,我当时就知道,这里就是问题所在。

     

  此时,二次加载的Web应用,也由于某些原因失败了。

    

5.  运维的同事,注意到了这些错误信息,由于重新启动了Tomcat,这次Tomcat正常启动了

     第一个Web应用正常启动了

     

    第二个Web应用也正常启动了,参看日志。

    

6.  于是在我们的Tomcat中就出现了两个一模一样的Web应用,换句话说,就是出现了两个一模一样的定时任务。 这个就是为什么定时任务会被执行2次的原因。

7. 解决以及应对

      7.1 不允许动态的在生产系统中,替换class文件

     7.2  在系统部署和上线过程中,需要进行日志分析,日志可以告诉我们一切的技术细节和内容。

     7.3  将Tomcat的Reloadable设置置为false

          <Context path="/helloApp" docBase="helloApp" debug="0" reloadable="false"/>  

8.  reloadable参数说明

     Context>代表了运行在<Host>上的单个Web应用,一个<Host>可以有多个<Context>元素,每个Web应用必须有唯一的URL路径,这个URL路径在<Context>中的属性path中设定。      

    <Context path="/helloApp" docBase="helloApp" debug="0" reloadable="true"/>  
<Context>元素的属性:
path:指定访问该Web应用的URL入口。
docBase:指定Web应用的文件路径,可以给定绝对路径,也可以给定相对于<Host>的appBase属性的相对路径,如果Web应用采用开放目录结构,则指定Web应用的根目录,如果Web应用是个war文件,则指定war文件的路径。
reloadable:如果这个属性设为true,tomcat服务器在运行状态下会监视在WEB-INF/classes和WEB-INF/lib目录下class文件的改动,如果监测到有class文件被更新的,服务器会自动重新加载Web应用。
在开发阶段将reloadable属性设为true,有助于调试servlet和其它的class文件,但这样用加重服务器运行负荷,建议在Web应用的发存阶段将reloadable设为false。

9.  总结

     由于一个微小的变化引发的问题,在这之前一直正常。由于动态替代class,引发自动部署;部署失败,导致出现了2个相同的部署包。再次重启,然后2个缓存包都正常启动。 其本质原因是Tomcat在卸载应用的过程中,如果出现异常,则无法继续删除缓存;在重新加载的时候,无法清空已有的缓存,这个才是问题的根源。

    我们姑且把这个问题,作为Tomcat的一个bug吧,只在特定情况下才会出现的问题。

    

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 创作都市 设计师:CSDN官方博客 返回首页