Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

What is the default, "sane" configuration for setting up a quartz 1.7 scheduler clustered with terracotta, where spring is managing the jobs/triggers?

We are having trouble figuring out all the settings we need to tweak in order to achieve the following behavior:

* We want all jobs to be clustered and "fail-over" if a node running that job dies/is shut down during the job.

What we are interested in is two things. First, quartz.properties file should have the following:

* org.quartz.jobStore.class = org.terracotta.quartz.TerracottaJobStore
* org.quartz.jobStore.isClustered = true

(as stated here: http://www.terracotta.org/documentation/ga/product-documentation-11.html#50491405_29905)

What else SHOULD or SHOULD NOT be set in quartz.properties that would specifically inhibit clustered job behavior?

Here is our complete quartz.properties for reference. Are we doing anything wrong here?

Code:

 org.quartz.scheduler.instanceName = DefaultQuartzScheduler
 org.quartz.scheduler.instanceId = stellaQuartzSchedulerId
 org.quartz.scheduler.rmi.export = false
 org.quartz.scheduler.rmi.proxy = false
 org.quartz.scheduler.wrapJobExecutionInUserTransaction = false
 
 org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
 org.quartz.threadPool.threadCount = 50
 org.quartz.threadPool.threadPriority = 5
 org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true
 
 org.quartz.jobStore.misfireThreshold = 60000
 
 org.quartz.jobStore.class = org.terracotta.quartz.TerracottaJobStore
 org.quartz.jobStore.isClustered = true

Next, we need to know how Spring Jobs should be configured. Our trigger bean "prototype" looks like this:

Code:

     <!-- run every night at midnight -->
     <bean id="midnightTrigger" parent="cronTriggerBean">
         <property name="jobDetail">
             <bean class="org.springframework.scheduling.quartz.JobDetailBean">
                 <property name="name" value="Midnight Job"/>
                 <property name="jobClass" value="company.jobs.MidnightJob"/>
                 <property name="volatility" value="true"/>
             </bean>
         </property>
         <property name="cronExpression" value="0 0 0 * * ?"/>
     </bean>

The thing that looks most suspicious here is the "volatility" property we set on the JobDetailBean. Additionally, it seems like we should be setting the "requestsRecovery" property to "true" to ensure the desired fail-over behavior mentioned earlier in this post.

Thank you for your help.

OK. Found these instructions here for the "custom" install:

http://www.terracotta.org/documentation/ga/product-documentation-12.html#300212368_pgfId-1001904

and after reading through those and some debugging we figured out where things were breaking down.

We had to make the following changes:

* Make sure your quartz.properties are ACTUALLY being loaded - we ended up configuring ours statically in our quartz.spring.xml:

Code:

 <bean id="quartzScheduler" class="org.springframework.scheduling.quartz.SchedulerFactoryBean" >
   <property name="quartzProperties">
            <props>
              <prop key="org.quartz.jobStore.class">org.quartz.jobStore.class = org.terracotta.quartz.TerracottaJobStore</prop>
            </props>
         </property>

Previously, our quartz.properties were being loaded via a command-line argument but I suppose that went away when we moved from 1.6 to 1.7?

* Made sure everything we're putting in job data maps are serializable

However we still have questions about the suggested configuration properties for quartz and for the jobs/triggers specifically, as stated above.

Yes, if you want fail-over of executing jobs, then you must set requestsRecovery=true for the particular job.

The proper value for volatility really depends on your entire setup and intentions. Typically you do not want triggers or jobs to be volatile - because that means they will be deleted from the store with the scheduler restarts. However if your application boot-strapping/configuration is setup to always add the jobs and triggers in your config files during startup, then perhaps you do want volatility - otherwise you may encounter "already exists" exceptions as they are added again and again each time the scheduler restarts. Such a setup (always adding the same triggers/jobs as the application starts) can be particular troublesome if the application is clustered - as each node (with the same deployment config) will be trying to add the same data to the scheduler.

Also, if you want persistent store of your job data (e.g. not lose jobs/triggers when the terractotta server restarts) you need to configure it to store it's data on disk, or setup a redundant array of terracotta servers.