Working with Quartz Scheduler Part 1
This article gives the guidelines to use quartz scheduler for a transnational application.
This article focuses on basic setup of quartz, holiday calendar, job dependency .
The part II of the article will delve on misfire handling, exception management and configuration setup.
There are several tasks in applications especially transnational applications which should run at a scheduled date and time.
There are following concepts or requirements which should be taken care by the scheduler
- EOD process: The scheduled tasks should run at the ?End Of Day? every day
- Cut-off time: The EOD for a current day is considered to be when cut-off day is passed. The EOD processes are triggered only after Cut-off time us passed. The transaction happening the system after cut-off time are considered as ?next days? transactions and would not be considered in current days EOD process E.g. the cut-off day for the current day us set as 8:00 PM .
- Holiday calendar: Some of the EOD process should not run on following days:
- Bank Holidays
Any scheduler should satisfy above conditions.
The recommended scheduler is based on ?Quartz? framework (http://quartz-scheduler.org/).
Reasons for recommending quartz:
- Open source.
- Active community support.
- Most well-known scheduler for Java used by many financial applications.
- Proven performance scalable to clustered environment
- Ability to incorporate holiday calendar.
- Abilities can be extended by using Terracotta extensions (with License fee) for
- Graphical scheduler
- Capability to deploy different jobs at different nodes
- Run jobs in memory taking terabytes(like interest calculation of million of wallets ) using ?BigMemory?
There are following components to setup the scheduler
Include following maven dependencies
Web.xml: add following
- The Quartz properties are given in ?Quartz.properties? file (Described later).
- The Listener class provided b y quartz distribution initializes the Scheduler factory based on the context parameters defined in the web.xml.
- The servlet, in its init() method, initializes the scheduler and puts the jobs into it
Put the quartz.properties file in the resources folder in project structure ?src/main/resources? so that it can be picked up in the class path
The meaning of elements in properties file is given here(http://quartz-scheduler.org/documentation/quartz-2.2.x/configuration ) . We will update the properties file based on performance benchmarking. For development, the above properties file suffices.
SchedulerFactory: This class is created in the Listener provided by Quartz. Factory class creates a Scheduler.
Scheduler : An instance Scheduler interface maintains a registry of ?JobDetail? and ?Triggers?. It also provides the APIs for a adding the Jobs, triggers, calendars etc. The Scheduler instance is produced by the SchedulerFactory class.
Job: This is the interface to be implemented by classes that intend to do processing at a scheduled time. An example of Job is ?InterestAccrualManager?, GLPostingManager etc. The Job instance implements the execute() method which is the entry point of the processing that needs to be performed.
JobDetail: conveys the details of a given Job instance. Quartz does not actually stores the Job instance in the Scheduler, but adds a JobDetail in its registry which allows to create an instance of Job. Jobs have ?name? and ?Groups? attributes, which allow them to be uniquely added into a scheduler.
Trigger: Trigger is the mechanism by which a Job in the scheduler gets invoked. There can be more than one trigger for a single Job instance, but one trigger can be associated with only one Job instance via JobDetail. There are various type of triggers like:
- SimpleTrigger which helps in setting up simple Jobs such as trigger a job on a frequency.
- CronTrigger: Uses OS cron like syntax for setting up the trigger for a Job. The details of the cron setup are given here (http://www.quartz-scheduler.org/documentation/quartz-2.x/tutorials/crontrigger)
Builder classes: The JobDetail and Trigger instances are created by the Builder classes. There are different Builders for jobs and Triggers.
Calendar: The Quartz Calendar classes are different from Java Calendar. The Quartz Calendar interface instance implements two methods:
There are various calendars available, the most important for interest and GL use cases are AnnualCalendar and HolidayCalendar.
Calendar instances, when added to Schedular and trigger, make trigger not to fire based on certain condition e.g. a trigger set to fire every day 8:00 PM will not be fired on a Holiday if holiday calendar is defined in the trigger.
Steps for setting up a scheduler
- Get an instance of StdSchedulerFactory
- Create Scheduler: The scheduler is given a name
- Start Scheduler:
- Add Job to a scheduler : Create a JobDetail
- Create a trigger
- Adding a Holiday calendar: create an instance of Holidaycalendar
- Add Holidays to holidaycalendar instance
- Add HolidayCalendar to Scheduler
- Modify the Trigger Builder to take into account the HolidayCalendar
The requirement is to have an order of jobs or job dependency where one job runs only when another job is completed. If the first job fails the second job is not triggered at all.
e.g. Job 2 depends on Job1
Order execution : Job1 ? Job2
If Job1 fails Job2 is not triggred.
The quartz do not provide the direct interfaces to create the Job dependency.
However, the requirement can be met with a concept of ?Job Chaining? where ordered jobs are ?chained? to run together.
This can be achieved in two ways in Quartz.
- Use Job chaining with Quartz Listeners.
- Job chaining with JobDataMap
Both approaches require certain coding and there is no direct configuration to define the job dependency.
We will use the second option to implement the job dependency/chaining as it is less involved and more direct.
The JobDataMap is the data that is passed to the job from a trigger or another Job. We use the JobDataMap to pass the information on ?next? job to run in the chain after completion of current Job.
Following is the implementation details of Job chaining:
Suppose in an application there are two jobs that happen periodically
- Print card job
- Dispatch card Job
Clearly dispatch can happen only when card is printed. So there is a dependency.
Create an abstract class ChainableJob. Having abstract method doExecute()
All jobs having the dependency will extend the ChainableJob and implement job logic in doExecute().
The abstract class implements following methods
- calls abstract method doExecute() (implemented by base class) to execute the current job
- once the job is executed, calls the chain() method to execute the dependent job.
The chain method does the following.
- Gets the details of the job which is next in chain (dependant job) from the JobDataMap of the top level Job
- Creates the JobDetail of the dependent job.
- Schedules the job for immediate running using ?SimpleTrigger?
Steps for defining the top level Job job
- Define the dependent Job details in JobDataMap. Following details will need to be definef
- Dependent Job class
- Dependent job name
- Dependent job group
- Define the top level job e.g. printCardJob using the JobBuilder code snippet also add the JobDataMap while crating the job
- Create Trigger using triggerBuilder
- Scehdule top level job