-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Quartz API Operations
Quartz is a Java library, and you may use it to perform job data management and control the scheduler. The central API to the scheduler is the org.quartz.Scheduler interface, and you may get an instance with org.quartz.impl.StdSchedulerFactory.getDefaultScheduler(). You should study this org.quartz.Scheduler interface thoroughly in JavaDoc before using Quartz. When using this API, it is helpful to understand some terms used in regards to Quartz scheduling.
We refer to "client" API when you use org.quartz.Scheduler to manage job data only. Things such as adding, removing, rescheduling a job or trigger etc. These operations can be done on scheduler instance without having it to be started. Obviously you may also perform job data management while the scheduler is in running mode as well.
Quartz client would use org.quartz.Scheduler instance to perform job data management and then it can exit the JVM process if it choose so. This is specially true if the store is persistence such as the JDBCStore.
We refer to "server" API when you use org.quartz.Scheduler to control the scheduler. You may start, pause or shutdown the scheduler. Note that once a scheduler is shutdown, you can not reuse the instance to re-start it!
We also refer to quartz as "server" mode where scheduler is running with thread pool that execute the jobs once it has started. To keep the server JVM process up and running, the application will usually place the main thread to sleep or wait mode. The Quartz scheduler itself will start other threads to check triggers and execute jobs. This means the "server" should be keep alive and usually run in background.
Note that you can also use Quartz with both "client" and "server" mode in a same process. This is usually the case for small and single JVM scheduler.
You can configure the Quartz to run in cluster of machine nodes to share a single scheduler data store (eg: JDBCStore). In this case, each node can be a "client" to perform job data management, and each node can be "server" that runs the scheduler. Each running scheduler node will pick up next firing trigger from the cluster store in a random fashion and distribute the work. At this time, Quartz does not have ability to control where a job gets to be executed by a specific node in a cluster of nodes.
In cluster mode, it might be useful to have a dedicated node to be the "client" into the cluster for job data management only. In this case, you should NOT start the scheduler using this "client" API. This will help track the application debugging easier with log output etc, and it minimize affect of each running scheduler on the job execution. This "client" code can be a standalone Java process utility, or part of a UI web application. Again, you want to ensure this "client" is using same Scheduler name as part of ONE cluster, and will NOT start the scheduler, but to only manage job data.
Some application may choose to use Quartz Listener that will respond to events and then trigger job data changes. The listeners may be configured to run on each cluster node, and in that moment act as "client".
Quartz provides some listeners that you may register into the scheduler to receive callback processing. You can listen to jobs being added or removed, triggers being fired and when a job execution is completed. These listeners are only bound to the instance of the scheduler you registered!
Quartz allows you to enable RMI communication. In this case the quartz "server" will listen on a port (default: 1099) while running the scheduler as usual. A remote JVM process can connect to this quartz "server", and it will also receive the same org.quartz.Scheduler interface, but with different implementation obviously. Once a remote "client" is established, you can perform any job data management as usual. Care should be taken when invoking "server" mode related operations on a remote "client". Actions will affect the server immediately.
When using RMI mode, the quartz server job store can be RAMJobStore, and it still able to support a remote "client" that can connect and exit out of their own JVM process. As long as you keep the quartz "server" up and running, the scheduler and its jobs will be stored and run as usual.