公司的产线环境一直用spring-quartz做一些定时job,从来没有发生过问题。之前有一个每5秒处理一批任务的需求,也使用了spring-quartz,而且运行了几个月从来没有发生过job时间的问题。今天早上来公司被告知job停掉了。
通过查DB中最后执行任务的时间,是在早上7点,查最后一次启动job的前后日志,一点异常也没有,诡异啊。
我想起来之前在测试环境曾经为了测另一个程序的临界时间的问题,把测试环境的时间改来改去,导致测试环境的spring-quartz异常。
想到这似乎有点意思了,因为昨天我们线上环境加了一个每一小时同步几台服务器的crontab。为了验证我的猜测是正确的,在本地启动这个job,把时间向前、向后调整几次后发现问题重现了。
我们quartz的配置是cronExpression:
是不是配置成当上次job完成后,隔5秒后再启动下次job的配置就不会出现这个问题呢?
于是尝试了如下配置:
遗憾的是问题依然可以重现。
其他几个job都运行良好,可能每5秒一次的job比几分钟、几个小时的job更容易受时间同步服务的影响吧。没办法了,暂时先把这台服务器的时间同步停掉。
线上环境啊,血的教训。
通过查DB中最后执行任务的时间,是在早上7点,查最后一次启动job的前后日志,一点异常也没有,诡异啊。
我想起来之前在测试环境曾经为了测另一个程序的临界时间的问题,把测试环境的时间改来改去,导致测试环境的spring-quartz异常。
想到这似乎有点意思了,因为昨天我们线上环境加了一个每一小时同步几台服务器的crontab。为了验证我的猜测是正确的,在本地启动这个job,把时间向前、向后调整几次后发现问题重现了。
我们quartz的配置是cronExpression:
<bean id="smsTaskSendTigger" class="org.springframework.scheduling.quartz.CronTriggerBean">
<property name="jobDetail">
<ref bean="smsTaskSendTiggerBean" />
</property>
<property name="cronExpression">
<value>0/5 * * * * ?</value>
</property>
</bean>
是不是配置成当上次job完成后,隔5秒后再启动下次job的配置就不会出现这个问题呢?
于是尝试了如下配置:
<bean id="smsTaskSendTigger" class="org.springframework.scheduling.quartz.SimpleTriggerBean">
<property name="jobDetail">
<ref bean="smsTaskSendTiggerBean" />
</property>
<property name="repeatInterval">
<value>5000</value>
</property>
</bean>
遗憾的是问题依然可以重现。
其他几个job都运行良好,可能每5秒一次的job比几分钟、几个小时的job更容易受时间同步服务的影响吧。没办法了,暂时先把这台服务器的时间同步停掉。
线上环境啊,血的教训。