quartz笔记

The main Quartz library is named quartz-all-xxx.jar (where xxx is a version number).
In order to use any of Quartz's features, this jar must be located on your application's classpath.
Quartz depends on a number of third-party libraries (in the form of jars) which are included in the distribution .zip file in the
'lib' directory. To use all the features of Quartz, all of these jars must also exist on your classpath.
Quartz uses a properties file called (kudos on the originality) quartz.properties. This isn't necessary at first, but to use anything but
the most basic configuration it must be located on your classpath.

org.quartz.threadPool.threadCount
Can be any positive integer, although you should realize that only numbers between 1 and 100 are very practical. This is the number of
threads that are available for concurrent execution of jobs. If you only have a few jobs that fire a few times a day, then 1 thread is
plenty! If you have tens of thousands of jobs, with many firing every minute, then you probably want a thread count more like 50 or 100
(this highly depends on the nature of the work that your jobs perform, and your systems resources!).

Sample configuration of Logging Trigger History Plugin
The logging trigger history plugin catches trigger events (it is also a trigger listener) and logs then with Jakarta Commons-Logging.
See the class's JavaDoc for a list of all the possible parameters.
Sample configuration of Logging Trigger History Plugin
org.quartz.plugin.triggHistory.class = \
 org.quartz.plugins.history.LoggingTriggerHistoryPlugin
org.quartz.plugin.triggHistory.triggerFiredMessage = \
 Trigger \{1\}.\{0\} fired job \{6\}.\{5\} at: \{4, date, HH:mm:ss MM/dd/yyyy}
org.quartz.plugin.triggHistory.triggerCompleteMessage = \
 Trigger \{1\}.\{0\} completed firing job \{6\}.\{5\} at \{4, date, HH:mm:ss MM/dd/yyyy\}.

http://www.quartz-scheduler.org/docs/configuration/ConfigRAMJobStore.html
RAMJobStore is used to store scheduling information (job, triggers and calendars) within memory. RAMJobStore is fast and lightweight,
but all scheduling information is lost when the process terminates.

SimpleTrigger is handy if you need 'one-shot' execution (just single execution of a job at a given moment in time), or if you need to fire a job at
a given time, and have it repeat N times, with a delay of T between executions. CronTrigger is useful if you wish to have triggering based on calendar-like
schedules - such as "every Friday, at noon" or "at 10:15 on the 10th day of every month."

The name of a job or trigger must be unique within its group - or in other words, the true identifier of a job or trigger is its name + group.
If you leave the group of the Job or Trigger 'null', it is equivalent to having specified Scheduler.DEFAULT_GROUP.

If N Triggers are to fire at the same time, but there are only Z worker threads currently available, then the first Z Triggers with
the highest priority will get first dibs.