-
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().
We refer to "client" API when you use org.quartz.Scheduler to manage job data only. Things such as adding, removing, or rescheduling a job, trigger or listeners. These operations can be done on scheduler instance without having it to be started or. Obviously you may also perform job data management while the scheduler is in running mode as well.
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 "server" where scheduler is running with thread pool that execute the jobs once it has started. While a quartz "client" will not start the scheduler. Client simply get the org.quartz.Scheduler instance and perform job data management and then exit, while the Server would usually keep the JVM process running in the background.
Note that you can also use Quartz with both "client" and "server" mode in a same process.
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 in a cluster of nodes.
In cluster mode, it might be useful to have a dedicated node to as as "client" into the cluster for job data management only. This helps track the application debugging easier with log output etc, and it minimize affect of each running scheduler on the job execution.
Some application may choose to use Quartz Listener that respond to events that will trigger job data changes. The listeners may be configured to run on each cluster node, and in that moment act as "client". In this case, there is no control over as where and which machine node it will get executed!