Quartz scheduler: clustering - job executing twice

Question

I have a Java application which utilises Quartz 1.6.6. It is deployed onto Weblogic, the architecture of which includes two application servers.

The application includes a trigger process which runs regularly - once a minute. This is achieved using Spring 3.1.1 (with a org.springframework.scheduling.quartz.SchedulerFactoryBean).

I have included a quartz.properties file in the Java application's EAR file with a hope to be able to utilise Quartz's clustering facilities so that the application servers would synchronise themselves in order that the job is only run once per minute. However, on looking at the application log, it's obvious to see that from the messages produced, there are still two jobs being run every 60 seconds - one a few seconds behind the other.

The confusing this is that I have another Java application into which I have included Quartz scheduling and it seems to be working quite happily. This other application has an identical mechanism for firing a trigger every minute and from the logs I can see that the job is only being run once every 60 seconds.

Examples of times yesterday afternoon that the job has run:

15:10:46,984 15:10:49,583 15:11:46,961 15:11:49,561

Here's my quartz.properties file:

org.quartz.scheduler.instanceName=QuartzClusteredScheduler
org.quartz.scheduler.instanceId=AUTO

org.quartz.threadPool.class=org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount=5

org.quartz.dataSource.dbDS.driver=oracle.jdbc.driver.OracleDriver
org.quartz.dataSource.dbDS.URL=jdbc:oracle:thin:@MY_DB:1521:my_sid
org.quartz.dataSource.dbDS.user=username
org.quartz.dataSource.dbDS.password=password

org.quartz.dataSource.dbDS.maxConnections=5

org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.StdJDBCDelegate

org.quartz.jobStore.isClustered=true
org.quartz.jobStore.dataSource=dbDS
org.quartz.jobStore.tablePrefix=QRTZ_

I have had a look in the database at the Quartz-specific tables but there is no data at all in them, which would lead me to think that the properties file isn't being picked up for some reason. I can't see why, though, as I have included quartz.properties in the EAR file under WEB-INF/classes in the WAR.

Thanks in advance for any assistance.

Answer 1

could you see, in your logs, when your quartz scheduler started, such output :

[INFO] 23 Jul 10:41:08.813 PM main [com.mchange.v2.c3p0.C3P0Registry]
Initializing c3p0-0.9.1.1 [built 15-March-2007 01:32:31; debug? true; trace: 10]

[INFO] 23 Jul 10:41:08.842 PM main [org.quartz.impl.StdSchedulerFactory]
Using default implementation for ThreadExecutor

[INFO] 23 Jul 10:41:08.876 PM main [org.quartz.core.SchedulerSignalerImpl]
Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl

[INFO] 23 Jul 10:41:08.876 PM main [org.quartz.core.QuartzScheduler]
Quartz Scheduler v.2.2.0-SNAPSHOT created.

[INFO] 23 Jul 10:41:08.878 PM main [org.quartz.impl.jdbcjobstore.JobStoreTX]
Using thread monitor-based data access locking (synchronization).

[INFO] 23 Jul 10:41:08.879 PM main [org.quartz.impl.jdbcjobstore.JobStoreTX]
JobStoreTX initialized.

[INFO] 23 Jul 10:41:08.880 PM main [org.quartz.core.QuartzScheduler]
Scheduler meta-data: Quartz Scheduler (v2.2.0-SNAPSHOT) 'TestScheduler' with instanceId     'NON_CLUSTERED'
  Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.
  NOT STARTED.
  Currently in standby mode.
  Number of jobs executed: 0
  Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 12 threads.
  Using job-store 'org.quartz.impl.jdbcjobstore.JobStoreTX' - which supports         persistence. and is not clustered.


[INFO] 23 Jul 10:41:08.880 PM main [org.quartz.impl.StdSchedulerFactory]
Quartz scheduler 'TestScheduler' initialized from default resource file in Quartz         package: 'quartz.properties'

[INFO] 23 Jul 10:41:08.880 PM main [org.quartz.impl.StdSchedulerFactory]
Quartz scheduler version: 2.2.0-SNAPSHOT


[INFO] 23 Jul 10:41:08.949 PM main         [com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource]
Initializing c3p0 pool... com.mchange.v2.c3p0.ComboPooledDataSource [ acquireIncrement -> 3, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, dataSourceName -> 1hge1678o1eqj5izxjkbki|12b31a7c, debugUnreturnedConnectionStackTraces -> false, description -> null, driverClass -> org.apache.derby.jdbc.ClientDriver, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, identityToken -> 1hge1678o1eqj5izxjkbki|12b31a7c, idleConnectionTestPeriod -> 0, initialPoolSize -> 3, jdbcUrl -> jdbc:derby://localhost:1527//tmp/bug.db;create=true, lastAcquisitionFailureDefaultUser -> null, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime -> 0, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 5, maxStatements -> 0, maxStatementsPerConnection -> 120, minPoolSize -> 1, numHelperThreads -> 3, numThreadsAwaitingCheckoutDefaultUser -> 0, preferredTestQuery -> null, properties -> {user=******, password=******}, propertyCycle -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> false, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false ]

That would indicate that your quartz.properties is used and the JobStoreTX is chosen as the jobstore.

Answer 2

I have utilised the workaround: include the properties within the SchedulerFactoryBean definition within my application context XML file, instead of using quartz.properties.