Getting Started With Quartz.Net: Part 2
This is the second instalment of the Getting Started With Quartz.Net series. Part 1 covered how to set up a standalone Quart.Net server as a windows service. Part 2 covers the configuration of the server.
At this point you should have installed the Quartz.Net server as a standalone windows service. If you haven’t, Part 1 guides you through this process.
Now, let’s look at configuring the server. There are 3 files we need to look at: Quartz.Server.Service.exe.config, quartz.config and quartz_jobs.xml.
Quartz.Server.Service.exe.configFirst we will examine Quartz.Server.Service.exe.config, so open this file in your favorite editor. The distribution version of the file does minimal configuration here, only setting up the logging sub systems. Of interest here is the <log4net> section, which you can modify if you don’t want your service to log to the event log. If you’re not sure how to configure log4net, visit the log4net site and look at the log4net configuration examples.
quartz.configNext, let’s look at quartz.config, which contains the bulk of the configuration. This file has 3 “sections” that are worth looking at. The first “section” starts on line 7:
# configure thread pool info
quartz.threadPool.type = Quartz.Simpl.SimpleThreadPool, Quartz
quartz.threadPool.threadCount = 10
quartz.threadPool.threadPriority = Normal
Here you can change the number of threads in the threadpool by changing the threadCount property. This basically translates into how many jobs can run at the same time.
The next section starts on line 12 and initializes the JobInitializationPlugin, which will load up a set of jobs from an xml file when the server is started:
# job initialization plugin handles our xml reading, without it defaults are used -->
quartz.plugin.xml.type = Quartz.Plugin.Xml.JobInitializationPlugin, Quartz
quartz.plugin.xml.fileNames = ~/quartz_jobs.xml
The interesting part here is the last line, where you can tell the plugin which file to load the jobs from.
The final section configures the server so that it can be managed remotely. We won’t look at this section right now since we don’t need to change it to run the server.
quartz_jobs.xml
The last configuration file that we will look at is quartz_jobs.xml, which contains the jobs that will be loaded by the initialization plugin. The file available with the distribution includes a sample job configuration of a job that does absolutely nothing. This is the file where you want to set up your own jobs. You can configure your jobs here and then start up the Quartz.Net service. The plugin will then read this file and schedule the jobs. Part 3 of the series will cover how to configure jobs via the xml file.
To wrap up this post, there are a couple of things that are worth pointing out:
Running the server using these default configuration files will start up a server that:
At this point you should have installed the Quartz.Net server as a standalone windows service. If you haven’t, Part 1 guides you through this process.
Now, let’s look at configuring the server. There are 3 files we need to look at: Quartz.Server.Service.exe.config, quartz.config and quartz_jobs.xml.
Quartz.Server.Service.exe.configFirst we will examine Quartz.Server.Service.exe.config, so open this file in your favorite editor. The distribution version of the file does minimal configuration here, only setting up the logging sub systems. Of interest here is the <log4net> section, which you can modify if you don’t want your service to log to the event log. If you’re not sure how to configure log4net, visit the log4net site and look at the log4net configuration examples.
quartz.configNext, let’s look at quartz.config, which contains the bulk of the configuration. This file has 3 “sections” that are worth looking at. The first “section” starts on line 7:
# configure thread pool info
quartz.threadPool.type = Quartz.Simpl.SimpleThreadPool, Quartz
quartz.threadPool.threadCount = 10
quartz.threadPool.threadPriority = Normal
Here you can change the number of threads in the threadpool by changing the threadCount property. This basically translates into how many jobs can run at the same time.
The next section starts on line 12 and initializes the JobInitializationPlugin, which will load up a set of jobs from an xml file when the server is started:
# job initialization plugin handles our xml reading, without it defaults are used -->
quartz.plugin.xml.type = Quartz.Plugin.Xml.JobInitializationPlugin, Quartz
quartz.plugin.xml.fileNames = ~/quartz_jobs.xml
The interesting part here is the last line, where you can tell the plugin which file to load the jobs from.
The final section configures the server so that it can be managed remotely. We won’t look at this section right now since we don’t need to change it to run the server.
quartz_jobs.xml
The last configuration file that we will look at is quartz_jobs.xml, which contains the jobs that will be loaded by the initialization plugin. The file available with the distribution includes a sample job configuration of a job that does absolutely nothing. This is the file where you want to set up your own jobs. You can configure your jobs here and then start up the Quartz.Net service. The plugin will then read this file and schedule the jobs. Part 3 of the series will cover how to configure jobs via the xml file.
To wrap up this post, there are a couple of things that are worth pointing out:
Running the server using these default configuration files will start up a server that:
- Logs events to the windows event log
- Uses a memory based job store (more on this later)
- Loads jobs from an xml file
- Schedules a NoOpJob that runs every 3 seconds.
- Can be managed remotely