In this post we will explain in great detail how the Quartz.Net scheduler loads its configuration upon startup. Since the scheduler configuration did not change between versions 1.0 and 2.0, the information here is applicable to both Quartz.Net versions.
In Quartz.Net, the StdSchedulerFactory is responsible for configuring the scheduler. When the Quartz.Net scheduler is started, the factory will try to automatically configure a scheduler by looking for configuration information in different places:
- the hosting application’s configuration file
- a file specified in an environment variable
- the quartz.config file
- the embedded configuration file
Configuring From the Hosting Application’s Configuration File
First, the factory will try to load the scheduler configuration from the <quartz> section of your application’s config file. If you are running Quartz.Net as a windows service, then the service’s configuration file will be used. This file (Quartz.Server.exe.config) can be found in the same folder as the server executable. If you are hosting the Quartz.Net scheduler in your web application, then the web.config file will be checked.Configuring From A File Specified in an Environment Variable
If the factory was not able to load the quartz configuration section, then the second place it will check is the environment variables of the process. Specifically, the factory will check to see if the quartz.config environment variable has been defined. If such a variable exists and is not empty, the factory will try to load the configuration from whatever file is specified as the value of the variable. For example, let’s say that your configuration file is called myconfig.config. If you set the quartz.config environment variable equal to myconfig.config, then the scheduler will load the configuration information from the file named myconfig.config.Configuring From the Quartz.config File
Let’s assume that so far, the factory has not been able to load the scheduler’s configuration. The next step that the factory will take is to try to load a file called quartz.config from the same directory where the hosting application’s assembly was loaded. In fact, this is the file that an out-of-the-box Quartz.Net server/service installation uses to configure itself.Configuring From the Embedded Configuration File
If all of the previous configuration options fail, then the factory falls back on loading the configuration file that is embedded in the quartz assembly. In case you’re curious, here are the configuration properties that are embedded in the assembly:| Property | Value |
| quartz.scheduler.instanceName | DefaultQuartzScheduler |
| quartz.threadPool.type | Quartz.Simpl.SimpleThreadPool, Quartz |
| quartz.threadPool.threadCount | 10 |
| quartz.threadPool.threadPriority | Normal |
| quartz.jobStore.type | Quartz.Simpl.RAMJobStore, Quartz |
| quartz.jobStore.misfireThreshold | 60000 |
One Final Step
You’d think that by now, the whole configuration process is finished and the scheduler has been configured successfully. Well, the default scheduler factory takes one last step before giving you the configured scheduler.Here’s what happens just after your configuration is loaded: if any of the configuration properties that you set in a configuration are also present in the environment variables, then the factory will overwrite them with the environment value. This the expected behavior. However, due to a bug, this does not work in Quartz.Net 1.0, but is fixed in Quartz.Net 2.0.
4 comments:
There's one thing I haven't been able to find out. Let's say I want to have my configuration in a config.file (web.config or app.config). I want to override the connection string in the application cause I have to decrypt or something like that. What's the best way to do this?
Is the connection string being used for your job store or is it a connection string that your jobs will use to do some work?
Hi J and thank you for the reply. I am using the connection string for the job store.I wanted to keep all the general configuration in my .config file and set the connection string property in code:
properties["quartz.dataSource.default.connectionString"] = MyConnectionString;
and then
new StdSchedulerFactory(properties)
It seems that if I only try to populate the properties collection with the connection string it looses all the .config values.
I ended up putting all the Quartz.Net configuration in code.
Awesome bllog you have here
Post a Comment