我有像这样的Quartz Job
@PersistJobDataAfterExecution
@DisallowConcurrentExecution
public class MyJob{
public void execute(JobExecutionContext jec) throws JobExecutionException {
//connect to a FTP server, monitor directory for new files and download
//Using FTPClient of commons-net-3.5.jar
}
通过
触发作业JobDetail jobDetail = newJob(MyJob.class)
.withIdentity(jobName, DEFAULT_GROUP)
.usingJobData(new JobDataMap(jobProperties))
.build();
//trigger every minute
Trigger trigger = newTrigger()
.withIdentity(jobName, DEFAULT_GROUP)
.startNow()
.withSchedule(cronSchedule(cronExpression))
.build();
scheduler.scheduleJob(jobDetail,trigger);
每分钟触发一次工作。它适用于大约1周(10000次执行)并且莫名其妙地没有重新启动。日志中没有错误,并且看到它已完成先前的执行。其他进程正在正确触发。
将库升级到quartz-2.2.3
和commons-net-3.5
(查找FTP库中可能存在的错误)我设法持续了3周
我有Job
来监控Scheduler
,表示触发状态为BLOCKED
。应用程序服务器
Thread
TriggerState triggerState = scheduler.getTriggerState(triggerKey);
我还没有找到有关Quartz这类问题的文档,所以我怀疑是FTP库中的一个错误,它干扰了石英启动的线程,例如使用@PersistJobDataAfterExecution
我想知道它是否是一个已知问题或可能是一个错误所以我可以应用解决方案或解决方法(杀死石英作业how to stop/interrupt quartz scheduler job manually)
答案 0 :(得分:0)
在经常出现服务中断并且怀疑FTP连接错误阻止服务的几个月之后,我们终于实施了一个似乎可以解决问题的措施
现在每个流程执行都会执行:
FTPClient ftp = new FTPClient();
//Added connection timeout before connect()
ftp.setDefaultTimeout(getTimeoutInMilliseconds());
ftp.connect(host, port);
//Added more timeouts to see if thread locks disappear...
ftp.setBufferSize(1024 * 1024);
ftp.setSoTimeout(getTimeoutInMilliseconds());
奇怪的是,先前在connect()
中没有阻止该进程,该进程在没有重新启动的情况下继续并结束,但是在设置超时时问题没有再次发生