最近在做一个调度平台改造的项目,quartz在测试环境跑的是单机环境,生产上两台服务器做集群。

测试环境是ok的,生产上线后报错,一个类java.lang.classNotFoundException(注明:这个类被别人修改了名称,现在使用的新名字)

第一次:失败

从代码上排除了对旧的job类的引用(配置文件和类都排除了)

推测是服务器缓存了该类。

尝试:

  清除缓存,重启服务器,仍然报上述错误。

第二次:失败

   将生产上的配置拉到测试环境上,反复测试,重启服务器时会自动清除缓存。

推测是quartz的那个类为全局变量,在生产上会做同步。

  尝试:

   在测试环境上再次搭建一台调度服务器,从生产上将配置和执行全部拉到测试环境上,执行ok

  反复调试,仍然没有发现同步的迹象。

  没有重现生产上的异常,不敢上线了。

第三次:失败

 那么这个旧的job类究竟从哪里调用的?找不到头绪!会不会保存到数据库吧?

 当时觉得这个想法很搞笑,从设计的角度上来说,quartz应该不允许将别的类引入到自己的体系吧。

 但也没路可走,就查看数据库,看看有没有保存在数据库中。你猜对了,它对原原本本的躺在数据库的表中:

CREATE TABLE QRTZ_JOB_DETAILS(
JOB_NAME VARCHAR(200) NOT NULL,
JOB_GROUP VARCHAR(200) NOT NULL,
DESCRIPTION VARCHAR(250) NULL,
JOB_CLASS_NAME VARCHAR(250) NOT NULL,
IS_DURABLE VARCHAR(1) NOT NULL,
IS_VOLATILE VARCHAR(1) NOT NULL,
IS_STATEFUL VARCHAR(1) NOT NULL,
REQUESTS_RECOVERY VARCHAR(1) NOT NULL,
JOB_DATA BLOB NULL,
PRIMARY KEY (JOB_NAME,JOB_GROUP))
TYPE=InnoDB;

好吧! 查看该字段,发现确实是旧的类,被不是新的类。

那么为什么在测试环境中发现呢?

进入测试库,也没有发现旧的类,好吧。

第四次:成功

再次部署到生产上,还是报错:类找不到。

确认问题处在数据库中,我对quartz的表一张张的查找,仍然找不到这个记录,那就从写入库开始入手,查了quartz的代码,发现job_detail表中有个字段job_data,它的类型是blob,会不会存在这里呢?

确实,可以打开此blob查看,数据时放到这里了。

这个小心一些,再次检查是否有别的blob字段存放旧的job类,发现在triggers表中也有个字段job_data,至此问题发现了。可怎么解决呢?blob类型的数据不能直接通过update来执行,毕竟要考虑到编码的因素,拿就釜底抽薪,直接将类重构为以前的类。

从这次经历来看,旧项目果然是坑,我就直愣愣的掉进去了。

结论:

计算机是个理性的东西,故一切皆有可能,即便是最不可能的事情也要去一一确认。在查找问题时最好想清楚所有发生故障的可能,然后一一排除,直到找到最终的问题。

对web开发来说,解决此类问题的一般思路如下:

1,从全局的角度来看,应用程序,缓存,数据库是三大独立模块,这些部分都有可能发生异常,应该首先排查应用程序本身的异常(这个概率最大);其次是缓存(同步)模块排查;最后是数据库模块排查。

2,全局确定好的前提下,细分上述的模块,将可能出现的问题一一列出。

3,动手,验证想法。对一个好的开发者来说,动手只是验证的手段,思路才是最重要的。

 

posted on 2015-02-04 15:40  一天不进步,就是退步  阅读(14361)  评论(0编辑  收藏  举报