Terracotta Discussion Forums

Hi experts,
I use mysql backend as jobstore on quartz-1.8.4. In setting a job, I set both endless secondly SimpleTrigger and JobDetails to setVolatility(true). First I scheduled the job through code, and run. Then I remove the schedule job code, keep a simple scheduler.start() call and restart the JVM, I found the job is still scheduled and running every second. Is this a expected behavior of volatile job/trigger?

Here's my scheduler config:
######################

#============================================================================
# Configure Main Scheduler Properties
#============================================================================

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

org.quartz.scheduler.skipUpdateCheck = true

#============================================================================
# Configure ThreadPool
#============================================================================

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

#============================================================================
# Configure JobStore
#============================================================================

org.quartz.jobStore.misfireThreshold = 500

org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.StdJDBCDelegate
org.quartz.jobStore.useProperties=true
org.quartz.jobStore.dataSource=myDS
org.quartz.jobStore.tablePrefix=QRTZ_
org.quartz.jobStore.isClustered=true
org.quartz.jobStore.clusterCheckinInterval=2000

...

And I found if I set org.quartz.jobStore.isClustered to false. volatile feature seems to be OK. If I set this params to true, even when there's only one scheduler node in cluster, volatile cannot work.

Question is when quartz clear the volatile jobs/triggers, at shutting down, or at starting up? And what's the proper behavior in a cluster?

Suggest that,
1) Clear volatile jobs/triggers in starting-up (after experiment, found non-clustered scheduler just works like that)
2) If Whole cluster restarts, clear the volatile ones by first node who owns the lock (seems not implemented)

in JobStoreSupport class, line 603,
Code:

 if (!isClustered()) {
             try {
                 cleanVolatileTriggerAndJobs();
             } catch (SchedulerException se) {
                 throw new SchedulerConfigException(
                         "Failure occured during job recovery.", se);
             }
         }

IMHO it would be enhanced.

Volatile triggers are not deleted when cluster nodes start because it is presumed the cluster always exists (that there is typically at least one node running).

It would be a big bummer if three nodes were running, and when a fourth fired up the volatile data was wiped out!

BTW: The entire notion of volatility is removed with Quartz 2.0. No one uses the feature. If you do have need for non-persisted scheduling data, use a RAMJobStore.

BTW, there are a few places in the docs where it notes this behavior (though not right on the volatile attribute -- sorry), and, whenever you store volatile data in JDBCJobStore, it logs this:

Code:

   getLog().info("note: volatile jobs are effectively non-volatile in a clustered environment.");