michaelklishin / quartz-mongodb

A MongoDB-based store for the Quartz scheduler. This fork strives to be as feature complete as possible. Originally by MuleSoft.
Other
249 stars 203 forks source link

clusterCheckinInterval not respected #146

Closed GEverding closed 7 years ago

GEverding commented 7 years ago

Hey, I tried setting clusterCheckinInterval but it doesn't appear to be respecting the config. In the logs it still says that the checin interval is 7500. I've attached my config below.


# Use the MongoDB store
org.quartz.jobStore.class=com.novemberain.quartz.mongodb.MongoDBJobStore
# MongoDB URI (optional if 'org.quartz.jobStore.addresses' is set)
org.quartz.jobStore.mongoUri=mongodb://localhost:27017
# comma separated list of mongodb hosts/replica set seeds (optional if 'org.quartz.jobStore.mongoUri' is set)
#org.quartz.jobStore.addresses=host1,host2
# database name
org.quartz.jobStore.dbName=conductor-quartz
# Will be used to create collections like mycol_jobs, mycol_triggers, mycol_calendars, mycol_locks
org.quartz.jobStore.collectionPrefix=conductor
# thread count setting is ignored by the MongoDB store but Quartz requries it
org.quartz.threadPool.threadCount=1
org.quartz.jobStore.class=com.novemberain.quartz.mongodb.DynamicMongoDBJobStore

# turn clustering on:
org.quartz.jobStore.isClustered=true

# Must be unique for each node or AUTO to use autogenerated:
org.quartz.scheduler.instanceId=AUTO
# org.quartz.scheduler.instanceId=node1

# The same cluster name on each node:
org.quartz.scheduler.instanceName=conductor
## Quartz plugins
#

org.quartz.plugin.triggHistory.class = org.quartz.plugins.history.LoggingTriggerHistoryPlugin
org.quartz.plugin.jobHistory.class = org.quartz.plugins.history.LoggingJobHistoryPlugin
# Frequency (in milliseconds) at which this instance checks-in to cluster.
# Affects the rate of detecting failed instances.
# Defaults to 7500 ms.
org.quartz.scheduler.clusterCheckinInterval=1000

# Time in millis after which a trigger can be considered as expired.
# Defaults to 10 minutes:
org.quartz.scheduler.triggerTimeoutMillis=10000

# Time in millis after which a job can be considered as expired.
# Defaults to 10 minutes:
org.quartz.scheduler.jobTimeoutMillis=10000

# Time limit in millis after which a trigger should be treated as misfired.
# Defaults to 5000 ms.
org.quartz.scheduler.misfireThreshold=1000

# WriteConcern timeout in millis when writing in Replica Set.
# Defaults to 5000 ms.
org.quartz.scheduler.mongoOptionWriteConcernTimeoutMillis=10000
``
michaelklishin commented 7 years ago

Feel free to look into a pull request.

GEverding commented 7 years ago
    I've been digging around to try and figure it out but I can't figure out how the config gets read in. Can you point me in the right direction? 

    --

Garrett

On Fri, Mar 31, 2017 at 4:11 PM -0400, "Michael Klishin" notifications@github.com wrote:

Feel free to look into a pull request.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

michaelklishin commented 7 years ago

Job stores do not deal with property files, Quartz itself does. They are read using java.util.Properties.

Now that I think of it, the setting you are after is very likely not managed by job stores to begin with. Please leave a comment if you have evidence of the contrary.

GEverding commented 7 years ago
    I'm not so sure about that. Your code doesn't seem to accept the values. Reading in the values is definitely handled by quartz though.

Your default is 7500 which you set in code. The default for jdbc is 15000.  I'll keep digging and read up on quartz job stores.

    --

Garrett

On Fri, Mar 31, 2017 at 6:39 PM -0400, "Michael Klishin" notifications@github.com wrote:

Closed #146.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.