8 (30.11.2022 3M) Flashcards
Add info about CronTrigger https://www.quartz-scheduler.net/documentation/quartz-3.x/tutorial/crontriggers.html AdoJobStore, https://www.quartz-scheduler.net/documentation/quartz-3.x/tutorial/job-stores.html#ado-net-job-store-adojobstore Add info about clustering https://www.quartz-scheduler.net/documentation/quartz-3.x/tutorial/advanced-enterprise-features.html https://www.quartz-scheduler.net/documentation/quartz-3.x/configuration/reference.html#clustering misfire instructions,clusterin setu
Tell about RAMJobStore.
RAMJobStore is the simplest JobStore to use, it is also the most performant (in terms of CPU time). RAMJobStore keeps all of its data in RAM.
The drawback is that when your application ends (or crashes) all of the scheduling information is lost - this means RAMJobStore cannot honor the setting of “non-volatility” on jobs and triggers. For some applications this is acceptable - or even the desired behavior, but for other applications, this may be disasterous.
With what JobStore does clustering work?
Currently, it is available only with AdoJobstore (JobStoreTx) and essentially works by having each node of the cluster share the same database.
What features does Quarz.NET clustering provide?
Features include load-balancing and job fail-over (if the JobDetail’s “request recovery” flag is set to true).
Tell about basic clusterning setup.
Enable clustering by setting the quartz.jobStore.clustered property to “true”.
Each instance in the cluster should use the same copy of the quartz properties. Exceptions of this would be to use properties that are identical, with the following allowable exceptions: Different thread pool size, and different value for the quartz.scheduler.instanceId property. Each node in the cluster MUST have a unique instanceId, which is easily done (without needing different properties files) by placing AUTO as the value of this property. AUTO uses machine name as instanceId
Tell about three dangers related to clustering.
- Never run clustering on separate machines, unless their clocks are synchronized using some form of time-sync service (daemon) that runs very regularly (the clocks must be within a second of each other).
- Never start (scheduler.Start()) a non-clustered instance against the same set of database tables that any other instance is running (Start()ed) against. You may get serious data corruption, and will definitely experience erratic behavior.
- Monitor and ensure that your nodes have enough CPU resources to complete jobs. When some nodes are in 100% CPU, they may be unable to update the job store and other nodes can consider these jobs lost and recover them by re-running.
Tell about load balancing in clustering.
Load-balancing occurs automatically, with each node of the cluster firing jobs as quickly as it can. When a trigger’s firing time occurs, the first node to acquire it (by placing a lock on it) is the node that will fire it.
Only one node will fire the job for each firing. What I mean by that is, if the job has a repeating trigger that tells it to fire every 10 seconds, then at 12:00:00 exactly one node will run the job, and at 12:00:10 exactly one node will run the job, etc. It won’t necessarily be the same node each time - it will more or less be random which node runs it. The load balancing mechanism is near-random for busy schedulers (lots of triggers) but favors the same node for non-busy (e.g. few triggers) schedulers.
