Showing items from New in Quartz.Net 2.0

New in Quartz.Net 2.0–New Job File Format

The xml format for the quartz_jobs.xml file has changed in Quartz.Net 2.0. This is a breaking change, so you won’t be able to use your existing jobs file with the new version of Quartz.Net without updating it to the 2.0 format. If you’re interested in the details of what can be configured in this file, I would recommend looking at the xsd file that defines the schema for the file. The xsd file that defines the new file format can be downloaded directly from the source code repository, here.
Today I’m going to provide a sample quartz_jobs.xml file in the new format and walk you through the creation of the file. Alternatively, you can take a look at the default file (that will be) provided with the Quartz.Net 2.0 distribution, here.
The new file format starts off with the following root element:

<job-scheduling-data xmlns="http://quartznet.sourceforge.net/JobSchedulingData" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.0">

Right after the root node, our configuration file has two elements, which we will describe in detail below:
  1. The <processing-directives> element

  2. The <schedule> element

The <processing-directives> Element

The processing directives element contains two elements. The first element, <pre-processing-commands> is used to run commands prior to adding jobs and triggers to the scheduler. I’m not going to spend much time going over these in detail, but here is a list of the commands available to you:

  • delete the jobs in a group
  • delete the triggers in a group
  • delete a job
  • delete a trigger
If you find yourself in need of help with these elements, leave a comment and I will write a follow-up post.

The second element, <processing-directives>, lets you specify how the xml file is to be processed. Here you will find a familiar configuration setting (from Quartz.net 1.0), the <overwrite-existing-data> element. Setting this element’s value to true will replace any jobs currently scheduled with the new schedule given in the xml file (true is the default setting!). The <ignore-duplicates> element is the other element allowed under the <processing-directives> element.

The <schedule> Element

The <schedule> element is where we describe the jobs and triggers that we want to schedule. This section has also changed its format. Now, instead of grouping jobs and triggers under an element, jobs and triggers are all specified at the same level, and are not grouped under the job element, as was the case in version 1.0.

Under the <schedule> element, we can have <job> and <trigger> elements, which are the building blocks that we use to put together our schedule. Let’s take a look at these elements now.

The <job> Element

The <job> element is used to describe the IJob that we want the scheduler to execute. Job details are specified by using the following elements:
  • <name>
  • <group>
  • <description>
  • <job-type>
  • <durable>
  • <recover>
  • <job-data-map>
All of these elements serve the same purpose as they did in version 1 and, except for the job-data-map, they’re all simple types, so I’m not going to go into great detail here either. If you need a little more help with these, leave a comment and I’ll expand on the explanation as needed.

The job-data-map, being a complex element, supports an <entry> element inside. The <entry> element has <key> and <value> elements inside, which describe the job property to be added to the job map.

The <trigger> Element
The <trigger> element is used to describe the trigger that we want to attach to a given job. The xml file loader plugin supports 3 types of triggers:
  • simpleTriggerType
  • cronTriggerType
  • calendarIntervalTriggerType
These three trigger types are based on the abstractTriggerType, which has the following common elements:
  • <name>
  • <group>
  • <description>
  • <job-name>
  • <job-group>
  • <priority>
  • <calendar-name>
  • <job-data-map>
In addition to the elements listed above, each trigger type supports some additional elements. These additional elements are used to set parameters that are not common across all of the trigger types. The table below summarizes each of the trigger types and the elements they support.

Trigger Type Additional Elements
SimpleTrigger <misfire-instruction>,<repeat-count>,<repeat-interval>
CronTrigger <misfire-instruction>,<cron-expression>,<time-zone>
CalendarIntervalTrigger <misfire-instruction>,<repeat-interval>,<repeat-interval-unit>


I’m not going to go into detail here either. This is already a pretty long post, so if anybody needs more information leave me a comment and I will write a follow-up post.

Putting It All Together

At this point we’ve described all of the elements that are necessary to describe a job in the new Quartz.Net 2.0 xml format. To put it all together, here are the contents of a sample quartz_jobs.xml file that you can use as a guide:

<?xml version="1.0" encoding="UTF-8"?>
<!-- This file contains job definitions in schema version 2.0 format -->
<job-scheduling-data xmlns="http://quartznet.sourceforge.net/JobSchedulingData" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.0">
  <processing-directives>
    <overwrite-existing-data>true</overwrite-existing-data>
  </processing-directives>
  <schedule>
    <job>
      <name>nativeJobExample</name>
      <group>nativeJobExampleGroup</group>
      <description>Sample job for Quartz Server</description>
      <job-type>Quartz.Job.NativeJob, Quartz</job-type>
      <job-data-map>
        <entry>
          <key>command</key>
          <value>native_job_example.bat</value>
        </entry>
        <entry>
          <key>consumeStreams</key>
          <value>true</value>
        </entry>
      </job-data-map>
    </job>
    <trigger>
      <simple>
        <name>nativeJobExampleSimpleTrigger</name>
        <group>nativeJobExampleSimpleTriggerGroup</group>
        <description>Simple trigger example</description>
        <job-name>nativeJobExample</job-name>
        <job-group>nativeJobExampleGroup</job-group>
        <misfire-instruction>SmartPolicy</misfire-instruction>
        <repeat-count>5</repeat-count>
        <repeat-interval>10000</repeat-interval>
      </simple>
    </trigger>
  </schedule>
</job-scheduling-data>

This is a working example of a quartz_jobs.xml file that schedules a NativeJob using a SimpleTrigger. This example also shows how to configure the <job-data-map> to pass configuration information to the job.

I hope this post helps you in building a job configuration file for Quartz.Net 2.0.

            Continue Reading
          

        

        
        
        

        
        
        

          
          

            
New in Quartz.Net 2.0-No More IStatefulJob

            
            
Welcome to the the third post of my New in Quartz.Net 2.0 series. 
Goodbye IStatefulJob
Yes, it’s true. In Quartz.Net 2.0 the IStatefulJob has been marked as obsolete. To be sure, it’s still available to use, but if you are using IStatefulJobs you should think about migrating them to use the new Quartz.Net 2.0 features. 
The Disallow Concurrent Execution Attribute
So how do I implement an IStatefulJob in Quartz.Net 2.0? Fortunately, it’s not very hard to do. You just need to mark your IJob with the new DisallowConcurrentExecutionAttribute. Any jobs that have this attribute set are only allowed to run one instance of the job at a time. Keep in mind that an instance is defined by a JobKey (job name and group combination), which means that if you have the same job type scheduled with a different job name or a different job group, you may get more than one instance of that type of job running at the same time.
The Persist Job Data After Execution Attribute
Seems simple enough so far? Well, it is! There is only one other thing to consider. If you want the scheduler to persist the job’s state between executions, you must also add the PersistJobDataAfterExecutionAttribute to the class. This attribute tells the scheduler that you would like for it store the job’s JobDataMap once it is finished executing. 
One Last Thing
While you can use each of these attributes separately, if you are going to use the PersistJobDataAfterExecutionAttribute to persist your job’s state, you should always use the DisallowConcurrentExecutionAttribute, because if you don’t, you might find that your job state is corrupted due to race conditions.

            Continue Reading
          

        

        
        
        

        
        
        

          
          

            
New in Quartz.Net 2.0–Directory Scan Job

            
            
This is the second post of the New in Quartz.Net 2.0 series. Today we will look at the DirectoryScanJob, which is a new job in Quartz.Net 2.0. 
The DirectoryScanJob is very similar to the FileScanJob, which is available in Quartz.Net 1.0. As you can probably tell from the names, the main difference between the two jobs is that the DirectoryScanJob scans for changes in… you quessed it… a directory , whereas the FileScanJob scans for changes in… yes, you guessed it again… a file. If you’re not familiar with the FileScanJob, don’t worry, we will look at the DirectoryScanJob in detail.
Introducing the DirectoryScanJob
First, let’s take a look at what the documentation says about this new job:
“Inspects a directory and compares whether any files' "last modified dates" have changed since the last time it was inspected.  If one or more files have been updated (or created), the job invokes a "call-back" method on an identified DirectoryScanListener that can be found in the SchedulerContext.”
That seems pretty self explanatory, no? Basically, you tell the job that it needs to check a certain directory to see if new files have been added or if existing files have been modified. When the job is executed it checks the files and stores the file information in its JobDataMap. The next time the job runs, it compares the information stored in the job’s JobDataMap, with the files in the directory. If any changes are found, the job calls the FilesUpdatedOrAdded method of the IDirectoryScanListener that was configured for that job, passing in an arrary of FileInfo objects.
Configuring the DirectoryScanJob
To configure and use a DirectoryScanJob, you will need to set the following keys in the JobDataMap:
  1. DIRECTORY_NAME: this is the path to the directory that you want to monitor. 
  2. DIRECTORY_SCAN_LISTENER_NAME: this is the name of the DirectoryScanListener that should called if changes are detected 
  3. MINIMUM_UPDATE_AGE: this is an optional parameter which lets you specify how many milliseconds must have passed since the file’s last modified time in order to consider the file modified. If this parameter is not specified, it defaults to 5000 milliseconds. 
Possible Uses for the DirectoryScanJob
There are many uses for the DirectoryScanJob, so let’s list a few here:
  • You could replace any FileWatcher type services that you might have implemented 
  • Scan files uploaded by users for viruses 
  • Schedule other jobs to process files that have been copied to the directory for processing 
The next post in the series will cover a change to the IStatefulJob interface: it has been marked as obsolete and is replaced by a class attribute!

            Continue Reading
          

        

        
        
        

        
        
        

          
          

            
New in Quartz.Net 2.0–The Calendar Interval Trigger

            
            
This is the first post of what will become a series of posts highlighting the new features that will be available in Quartz.Net 2.0.
To kick off the series, we will take a look at the CalendarIntervalTrigger. This trigger is used to fire jobs based on a recurring calendar time interval. The following time intervals are available:
       IntervalUnit     
       Minute     
       Hour     
       Day     
       Week     
       Month     
       Year     
This trigger has a RepeatInterval property, which can be used to indicate that the trigger should fire every N intervals. For example, if you set the RepeatIntervalUnit to Week and the RepeatInterval to 2, your trigger will fire every two weeks.
Here is what the source code documentation says about this trigger:
A concrete ITrigger that is used to fire a IJobDetail based upon repeating calendar time intervals. 
The trigger will fire every N (see RepeatInterval) units of calendar time (see RepeatIntervalUnit) as specified in the trigger's definition.  This trigger can achieve schedules that are not possible with ISimpleTrigger (e.g because months are not a fixed number of seconds) or ICronTrigger (e.g. because "every 5 months" is not an even divisor of 12).
If you use an interval unit of IntervalUnit.Month then care should be taken when setting the startTime value that is on a day near the end of the month.  For example, if you choose a start time that occurs on January 31st, and have a trigger with unit IntervalUnit.Month and interval 1, then the next fire time will be February 28th, and the next time after that will be March 28th - and essentially each subsequent firing will occur on the 28th of the month, even if a 31st day exists.  If you want a trigger that always fires on the last day of the month - regardless of the number of days in the month, you should use ICronTrigger.
That’s it for today’s “New in Quartz.Net 2.0” post. Stay tuned for more, coming soon!

            Continue Reading