Software Experts
Call Us: +40 770 613 713 | EU
6th Jan 2015 | by: cetus

INTRODUCTION

Quartz.NET is a full-featured, open source job scheduling system that can be used from smallest apps to large scale enterprise systems (http://quartznet.sourceforge.net). It is a part of the open source Java job scheduling framework, Quartz.

The main components of Quartz.NET are:

  • The scheduler instance
  • The job (detail)
  • The job trigger

THE SCHEDULER INSTANCE

A scheduler instance acts as a server to execute scheduled jobs and/or to schedule the jobs themselves. We can schedule jobs using an instance and they will be executed by the instance if it has been started.
In order for the scheduler to function properly it needs to be configured. There are three ways to configure a scheduler:

a. The Application Configuration File

This is the method we are currently using for configuring both the executing instance and the scheduling one.
A new section must be added to the configSections in the configuration file:

This allows us to add the quartz configuration section which looks like this (this example is for an instance which should be used for executing jobs, not only scheduling them):

The instance name is the name of the scheduler instance and it will be used to save jobs. This name must be common to all scheduler instances, allowing us to schedule a job with one instance and execute it with another. In order to be able to run multiple scheduler instances in the same application or on the same machine (one to execute and one or more to schedule) we need to change for each one the instanceId, the port and the bindName. Otherwise, there will be an error on trying to schedule/execute jobs.

The threadPool settings control how many threads will be used for the instance. For example we can set the thread pool to 2 which means only 2 jobs will be executing at the same time.

It may be recommended to have multiple executing instances (one with many threads for small jobs, one with few threads for heavier jobs…), in which case the instanceName has to be the same when scheduling and executing (e.g. HeavyQuartz for the heavy ones and LightQuartz for the small ones).

The jobStore settings configure where and how to store the jobs themselves. The given example uses a database to store the jobs but we can also choose to work in memory by setting the job store type to RAM or not setting it at all (it is the default job type). Another possibility is working with an xml file.

The tablePrefix sets the prefix which is used for the quartz table names in the database, so this way we can have multiple scheduler instances mapping to different tables. The connectionStringName is the name of the connection string which has to be found in the configuration file in the connectionStrings section.

The scheduler is instantiated in this case in the following way:

b. The Quartz Properties File

This is another option and it needs to have a file in the application host called quartz.config. The settings are the same but the format is different:

The scheduler is instantiated in this case in the following way:

c. Hardcoding

The quartz instance can also be configured in the code by using a NameValueCollection:

THE JOB (DETAIL)

The job detail holds the data associated with a job. Each job to be scheduled and executed must have a corresponding class implementing the IJob interface. The only method to be implemented is Execute which will be launched when the time comes:

The context holds all the necessary data and objects related to the job, including the quartz instance itself. This also allows chaining jobs by scheduling a job at the end of another.

A job can have associated job data which is saved as a dictionary:

The JobDataMap also allows keeping more complex objects which are serialized. However, in this case we must make sure that we maintain back compatibility for those classes (to avoid problems on deserializing after updating a class).

THE JOB TRIGGER

The job trigger allows us to control the timing of the scheduler, when to execute it, how many times, what happens on misfire. The following example creates a trigger which will launch only once, two days from now.

More complex triggers can be created using cron triggers which allow a finer control (for example, every two minutes, between 12:40 – 13:00 on every Tuesday).

More details on the Quartz.NET can be found at http://quartznet.sourceforge.net and particularly at http://quartznet.sourceforge.net/tutorial/index.html.

DEVELOPMENT ISSUES

This section is used to highlight some of the issues that may come up when working with Quartz.Net, as well as some recommendations.

Backward Compatibility

When making changes to existent quartz jobs we have to make sure that they are backward compatible in terms of:

  • The stored data – the job data map allows us to store data for the job to access when it is executed. The danger when changing the job class is to add new data to the job data map. This way, if there are any old instances of the job in the database, the new code will try to get the new data which does not exist for the old jobs and an exception will be raised. This case must be covered.
  • The job class name or namespace. Another piece of data which is stored in the database is the job name and namespace, so again if this is changed old jobs will fail to execute.

Tracking/Debugging Quartz Jobs

It may be difficult to debug quartz jobs because of the multithreaded model.

Debugging Guidelines

Debug

Being launched in the scheduler the debug instance has to be on the scheduler as well to get into the job code. To enter services code the debug instance has to be on the business service layer.

Tracking Triggers

The main goal of quartz jobs is to take the load off the main user thread for smaller response times as well as a larger spread of the CPU usage (by executing the same task over a larger period of time). The point is that not all triggers lead to heavy work. In some cases the job only checks if anything needs to be done, the result is false so the job is done.

The number of triggers/jobs that are created can be quite large (as in the case of creating a subscription), so tracking them becomes difficult. This applies mostly to one time jobs such as emails or webhooks, other jobs such as assessing subscriptions or updating the cc status have only one instance.

1. Quartz Thread Count

Limit the quartz thread count to 1 (in order for quartz to execute a single job at any given time). To limit the thread count change the “quartz.threadPool.threadCount” property either in the application configuration or the configuration code (depending on how the qserver was configured).

Sometimes the job may not be launched on time because of the quartz delays or because the CPU is busy with some thing else. In order to increase the probability of launching jobs on time increase the thread priority to Normal:

2. Quartz Database

The database tables to follow are QRTZ_JOB_DETAILS and QRTZ_TRIGGERS.

A trigger’s NEXT_FIRE_TIME represents the next time when the trigger will be fired to execute it’s job and it is expressed in ticks.

The following utility sql script can be used to convert ticks to datetime and vice versa:

You can change the next fire time to a value in the future in order to postpone the execution of the job.

Triggers can also be deleted, in which case the job should be deleted as well (to avoid consistency problems). This allows us to single out particular triggers and make them easier to track.

The current executing jobs are those jobs with a status which is different from WAITING:

This script also retrieves triggers that may have been executed already and are completed, but these triggers still take one thread of the available ones, so technically it is still executing.

In the case of one time jobs (adding emails, webhooks) the trigger name contains some ids, depending on the job type (site id, customer id, subscription id). Check the code in order to see what data is put into the name.

Quartz Issues

Some issues were observed while working with the Quartz scheduler. Some triggers that were left behind were no longer launched by the scheduler. This was reported on several machines but seldom. During a major deploy the jobs which accumulated for the scheduler on the Production server were not launched, in large numbers. On a close investigation of the issue the conclusion was that the jobs were not launched in time and they were considered misfired. All the jobs are created with the instruction to be launched immediately in case of misfire, however, the instruction most probably failed.

As part of the solution we increased the number of threads assigned to the scheduler, in order to avoid large numbers of triggers accumulating in times of heavy data processing. We also increased the misfire threshold from its 60 seconds default, to an entire day.

Share This Post

About the Author: cetus

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">