Difference between revisions of "Configuring the Quartz Scheduler"
imported>Aeric |
imported>Aeric |
||
Line 10: | Line 10: | ||
:1. Enable qrtz_manager_instance = 1. This is available at <tt>{install_dir}/profiles/LJP/configuration/tomcat/conf/RN/networking.properties</tt> | :1. Enable qrtz_manager_instance = 1. This is available at <tt>{install_dir}/profiles/LJP/configuration/tomcat/conf/RN/networking.properties</tt> | ||
:2. Edit <tt>{install_dir}/profiles/LJP/configuration/tomcat/conf/RN/AALSchedulers.xml</tt> | :2. Edit <tt>{install_dir}/profiles/LJP/configuration/tomcat/conf/RN/AALSchedulers.xml</tt> | ||
:4. Add the following information: | :4. Add the following information: | ||
::a. Database user name (an admin user) | ::a. Database user name (an admin user) |
Revision as of 11:11, 10 August 2017
Important:
- Quartz must be enabled on at least one platform instance, or the platform won't run.
- If you have multiple instances, Quartz should run on only one of them, unless you follow the Quartz clustering instructions below.
- Changing the quartz configuration requires a restart of all Application Servers.
Enabling Quartz on a Platform Instance
- 1. Enable qrtz_manager_instance = 1. This is available at {install_dir}/profiles/LJP/configuration/tomcat/conf/RN/networking.properties
- 2. Edit {install_dir}/profiles/LJP/configuration/tomcat/conf/RN/AALSchedulers.xml
- 4. Add the following information:
- a. Database user name (an admin user)
- b. Password for that user
- Example:
<attribute name="org.quartz.dataSource.myDS.URL" value="jdbc:mysql:"/> <attribute name="org.quartz.dataSource.myDS.user" value=""/> -- root user <attribute name="org.quartz.dataSource.myDS.password" value=""/> -- password
Moving Quartz to Another Platform Instance
Suppose you have one application server instance, and you have decided to add another to handle the traffic volume. And let's say you also decide to move quartz to the new instance, to further reduce the load on the original server. To that, you disable Quartz on the first instance, and start it on the second.
- 1. Disable qrtz_manager_instance = 0. This is available {install_dir}/profiles/LJP/configuration/tomcat/conf/RN/networking.properties
- 2. For the second instance, follow the steps above, in Setting up Quartz on a Platform Instance
Setting up a Quartz Cluster
By default, Quartz is pre-configured to run as a cluster of instances running on different servers. To run successfully, however, each server must have the settings shown here. Otherwise, a Quartz instance will not know that the others exist, and will not lock job records that are in progress. Perform this configuration on any server you later add to the cluster.
- 1. Open {install_dir}/profiles/LJP/configuration/tomcat/conf/RN/AALSchedulers.xml
- 2. Check this line:
<attribute name="org.quartz.scheduler.instanceId" value="AUTO" [VERIFY THIS LINE]
- 3. Under # Configure JobStore, check these lines:
... # Configure JobStore <attribute name="org.quartz.jobStore.misfireThreshold" value="60000"/> [VERIFY THESE LINES] <attribute name="org.quartz.jobStore.isClustered" value="true"/> <attribute name="org.quartz.jobStore.clusterCheckinInterval" value="20000"/>
In addition, MySQL must be configured to set the appropriate transaction-isolation level and to specify row-based replication:
- Edit {MYSQL_INSTALLATION}/my.cnf
- Use the following settings:
transaction-isolation = READ-COMMITTED binlog-format = ROW