-
Robert Roland authored
It's possible for the scheduler to get in a weird state if the sync fails while it executes. This change makes it *only* recreate a job/task if the schedule has changed or if it is missing. Previously, clearing the state at every start had bad effects if the JVM had terminated during the sync. Adds a vector of Exception classes that signal a "fatal" exception during sync for a specific database. If these exceptions occur, the sync for that database stops and will pick up next time. This will have to be expanded per driver, but I don't see a way around that, as each driver will have its own, unique way of failing. metabase/metabase#14817
Robert Roland authoredIt's possible for the scheduler to get in a weird state if the sync fails while it executes. This change makes it *only* recreate a job/task if the schedule has changed or if it is missing. Previously, clearing the state at every start had bad effects if the JVM had terminated during the sync. Adds a vector of Exception classes that signal a "fatal" exception during sync for a specific database. If these exceptions occur, the sync for that database stops and will pick up next time. This will have to be expanded per driver, but I don't see a way around that, as each driver will have its own, unique way of failing. metabase/metabase#14817
Code owners
Assign users and groups as approvers for specific file changes. Learn more.
quartz.properties 1.95 KiB
org.quartz.scheduler.instanceName = MetabaseScheduler
org.quartz.scheduler.instanceId = AUTO
# default is 10
org.quartz.threadPool.threadCount = 10
# Don't phone home
org.quartz.scheduler.skipUpdateCheck = true
# Use the JDBC backend so we can cluster when running multiple instances!
# See http://www.quartz-scheduler.org/documentation/quartz-2.x/configuration/ConfigJDBCJobStoreClustering
# http://www.quartz-scheduler.org/documentation/quartz-2.x/configuration/ConfigJobStoreTX.html
# http://www.quartz-scheduler.org/documentation/quartz-2.x/configuration/ConfigDataSources.html
# http://clojurequartz.info/articles/durable_quartz_stores.html
org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.StdJDBCDelegate
org.quartz.jobStore.dataSource=db
org.quartz.jobStore.isClustered = true
# By default, Quartz will fire triggers up to a minute late without considering them to be misfired; if it cannot fire
# anything within that period for one reason or another (such as all threads in the thread pool being tied up), the
# trigger is considered misfired. Threshold is in milliseconds.
#
# Default threshould is one minute (60,000)
# We'll bump it up to 15 minutes (900,000) because the sorts of things we're scheduling aren't extremely time-sensitive,
# for example Pulses and Sync can be sent out more than a minute late without issue. (In fact, 15 minutes late is better
# than not at all for such things)
org.quartz.jobStore.misfireThreshold=900000
# Useful for debugging when Quartz jobs run and when they misfire
#org.quartz.plugin.triggHistory.class = org.quartz.plugins.history.LoggingTriggerHistoryPlugin
#org.quartz.plugin.triggHistory.triggerFiredMessage = Trigger \{1\}.\{0\} fired job \{6\}.\{5\} at: \{4, date, HH:mm:ss MM/dd/yyyy}
#org.quartz.plugin.triggHistory.triggerCompleteMessage = Trigger \{1\}.\{0\} completed firing job \{6\}.\{5\} at \{4, date, HH:mm:ss MM/dd/yyyy\}.