This scheduler instance is still active but was recovered by another instance in the cluster

简介: This scheduler instance is still active but was recovered by another instance in the cluster

报错信息

WARN org.quartz.impl.jdbcjobstore.JobStoreSupport.findFailedInstances(JobStoreSupport.java:3396) 
This scheduler instance (XXX) is still active but was recovered by another instance in the cluster. 
This may cause inconsistent behavior.

产生原因


使用Quartz时集群下的各机器时间不同步,在相同的数据库(集群)下,存在另外一个相同的应用(可能是测试或其他开发环境)已经在执行该定时任务,Quartz为保证数据一致性,后启动的定时任务不会执行。


解决方案


关掉另外一个地方的定时任务,重启当前应用。

相关文章
|
2月前
|
SQL 开发框架 安全
【译】You probably should stop using a custom TaskScheduler
以更明确的方式控制并发 我认为并发控制(又称速率限制)是应用程序非常重要的方面,重要的方面应该是明确的。 TaskScheduler 相当低级别的工具,我宁愿拥有更高级别的工具。如果工作是 CPU 密集型的,那么 PLINQ 或类似 ActionBlock TPL DataFlow 的东西可能是更好的选择。 如果工作主要是 IO 绑定和异步的,那么可以使用 Parallel.ForEachAsync 或 Polly.RateLimiting 基于 的 SemaphoreSlim 自定义帮助程序类。 结论
43 3
|
4月前
|
Linux 网络安全 调度
DolphinScheduler 调度工作流报错 Host key verification failed.
DolphinScheduler调度任务失败,错误显示"Host key verification failed."。问题可能在于SSH免密登录配置失效或租户不存在于Linux系统中。解决方案:检查SSH配置并确保调度用户有管理员权限;确认DolphinScheduler租户与Linux用户对应。如果日志仅显示主机键验证失败,可能忽略了租户与操作系统用户的对应关系。创建具备管理员权限的新租户可解决。此外,当失败策略设为"继续"时,可能无法查看失败日志,建议使用"结束"策略。
|
4月前
|
Kubernetes 容器
Warning FailedScheduling 14m (x12 over 16m) default-scheduler 0/1 nodes are available: 1 node(s
Warning FailedScheduling 14m (x12 over 16m) default-scheduler 0/1 nodes are available: 1 node(s
107 0
|
数据库
This scheduler instance (XXXXX) is still active but was recovered by another
This scheduler instance (XXXXX) is still active but was recovered by another
198 0
|
Java 调度
Leetcode-Medium 621. Task Scheduler
Leetcode-Medium 621. Task Scheduler
105 0
Leetcode-Medium 621. Task Scheduler
|
SQL Oracle 关系型数据库