1 Basic information Abstract: Quartz is an open-source job scheduling framework that is written entirely in Java and designed for use in J2SE and Java EE applications. It provides a great deal of flexibility without sacrificing simplicity. You can use it to create simple or complex schedules for executing a job. It has many features, such as database support, clustering, plug-ins, EJB job pre-build, JavaMail and others, support for cron-like expressions, and so on. Where the cluster configuration is generally more complex, then how to configure its cluster features in quartz? Wu Yuhou View the second part of this article: http://gocom.primeton.com/modules/newbb/forumtopic19180_9963_40.htm 2 Quartz cluster configuration Quartz is an open-source job scheduling framework that is written entirely in Java and designed for use in J2SE and Java EE applications. It provides a great deal of flexibility without sacrificing simplicity. You can use it to create simple or complex schedules for executing a job. It has many features, such as database support, clustering, plug-ins, EJB job pre-build, JavaMail and others, support for cron-like expressions, and so on. Where the cluster configuration is generally more complex, then how to configure its cluster features in quartz? 2.1 Fundamentals of cluster implementation Currently the latest version of quartz is 1.6.0. Quartz is implemented through the use of relational databases and JDBC job stores for cluster management.
1. Principle
Clustering provides high availability and scalability to the scheduler through failover and load balancing capabilities. The current cluster can only work in Jdbc-jobstore (JOBSTORETX or JOBSTORECMT) mode, essentially, is to enable each node on the cluster to work by sharing the same database (quartz the cluster management by starting two maintenance threads to maintain the database state, one is to detect the node state thread and one is the recovery task thread). Load balancing is done automatically, and each node in the cluster triggers the task as soon as possible. When the trigger time of a trigger arrives, the first node gets the task (through locking) and becomes the node that executes the task. Failover occurs when a node is performing one or more tasks that fail. When one node fails, the other node detects and identifies the task in the database that is in progress on the failed node. Any task that is marked as recoverable (the "Requests recovery" property of the task details) will be re-executed by the other nodes. Tasks that are not marked for recovery will only be freed and will be executed the next time the relevant trigger is triggered. 2. Tables used for cluster management --Task Detail table
- CREATE TABLE Qrtz_job_details
- (
- Job_name VARCHAR2 (+) not NULL,
- Job_group VARCHAR2 (+) not NULL,
- DESCRIPTION VARCHAR2 (+) NULL,
- Job_class_name VARCHAR2 () not NULL,
- Is_durable VARCHAR2 (1) Not NULL,
- Is_volatile VARCHAR2 (1) Not NULL,
- Is_stateful VARCHAR2 (1) Not NULL,
- Requests_recovery VARCHAR2 (1) Not NULL,--recoverable token
- Job_data BLOB NULL,
- PRIMARY KEY (Job_name,job_group)
- );
--Trigger and Task Association table
- CREATE TABLE Qrtz_fired_triggers
- (
- entry_id VARCHAR2 () not NULL,
- Trigger_name VARCHAR2 (+) not NULL,
- Trigger_group VARCHAR2 (+) not NULL,
- Is_volatile VARCHAR2 (1) Not NULL,
- instance_name VARCHAR2 (+) not NULL,
- Fired_time number () is not NULL,
- State VARCHAR2 (+) is not NULL,
- Job_name VARCHAR2 (+) NULL,
- Job_group VARCHAR2 (+) NULL,
- Is_stateful VARCHAR2 (1) NULL,
- Requests_recovery VARCHAR2 (1) NULL,--recoverable token
- PRIMARY KEY (entry_id)
- );
--Scheduler State table
- TABLE qrtz_scheduler_state
- (
- Instance_name VARCHAR2 (a) not NULL,--Scheduler instance ID
- Last_checkin_time number (not NULL)--Last check time
- Checkin_interval number (in) not NULL,--Check time interval
- Recoverer VARCHAR2 () NULL,--Recovery scheduler
- PRIMARY KEY (instance_name)
- );
2.2 Cluster configuration Activate the cluster attribute by setting the "org.quartz.jobStore.isClustered" property to "true". Each instance in the cluster must have a unique "instance ID" ("org.quartz.scheduler.instanceId" attribute), but there should be the same "scheduler Instance name" (" Org.quartz.scheduler.instanceName "), which means that each instance in the cluster must use the same quartz.properties configuration file. In addition to the following exceptions, the contents of the configuration file must be the same: ? Different thread pool sizes,
? Different "Org.quartz.scheduler.instanceId" attribute values (this can be easily done, set to "AUTO").
? Note: Never run a cluster on a different machine unless their clock is running very regularly (the clock must be within a minute) to synchronize with some form of synchronization service (daemon). Also: Never trigger a non-clustered instance if other instances are running on the same database table. You will severely corrode your data and cause unexpected behavior.
? For examples and detailed configuration instructions, please refer to Appendix Quartz configuration file Description. 3 Appendices 3.1 Quartz configuration file description 3.1.1 Quartz configuration file Basic description File name: Default file name Quartz.properties, you can load a custom configuration by changing the system Properties "Org.quartz.properties".
Format: Properties File 3.1.2 Quartz configuration File Detailed description 3.1.2.1 configuration of Scheduler main properties
- # Scheduler The general definition pattern for the main attribute is as follows:
- #
- # org.quartz.scheduler.instanceName = Sched_name
- # org.quartz.scheduler.instanceId = instance_id
- # org.quartz.scheduler.threadName = Thread_name
- # Org.quartz.scheduler.rmi.export = False
- # Org.quartz.scheduler.rmi.proxy = False
- # org.quartz.scheduler.rmi.registryHost = localhost
- # Org.quartz.scheduler.rmi.registryPort = 1099
- # org.quartz.scheduler.rmi.createRegistry = Never
- # Org.quartz.scheduler.userTransactionURL = user_tx_location
- # org.quartz.scheduler.wrapJobExecutionInUserTransaction = Jobs_in_user_tx
- # org.quartz.scheduler.idleWaitTime = Idle_wait_time
- # org.quartz.scheduler.dbFailureRetryInterval = Db_failure_retry_interval
- # Org.quartz.scheduler.classLoadHelper.class = Class_load_helper_class
- # Org.quartz.context.key.SOME_KEY = some_value
Here are the specific instructions:
Configuration of the 3.1.2.2 thread pool (ThreadPool) Here are the specific instructions:
- # Customizing a thread pool's general pattern is as follows:
- #
- # Org.quartz.threadPool.class = Org.quartz.simpl.SimpleThreadPool
- # Org.quartz.threadPool.threadCount = Thread_count
- # org.quartz.threadPool.threadPriority = Thread_prio
- #
- # option parameters for simple thread pool (simplethreadpool):
- #
- # org.quartz.threadPool.makeThreadsDaemons = Daemon_threads
- # org.quartz.threadPool.threadsInheritGroupOfInitializingThread = Inherit_grp
- # org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = Inherit_ldr
- #
- # or
- #
- # Org.quartz.threadPool.class = Com.mycompany.goo.FooThreadPool
- # Org.quartz.threadPool.somePropOfFooThreadPool = somevalue
- #
|
