Chapter 6. Immutant Jobs
Jobs in Immutant are simply functions that execute on a recurring schedule. They fire asynchronously, outside of the thread where they are defined, and fire in the same runtime as the rest of the application, so have access to any shared state.
Jobs are built on top of the Quartz library, and support scheduling via a cron-like specification or a more finer-grained at-style syntax.
6.2. Scheduling Jobs
Scheduling a job is as simple as calling immutant.jobs/schedule:
(ns my.ns (:require [immutant.jobs :as jobs])) (jobs/schedule "my-cron-job-name" #(println "I fire every 5s, forever.") "*/5 * * * * ?" :singleton false) (jobs/schedule :my-at-job-name #(println "I fire 4 times with a 10ms delay between each, starting in 500ms.") :in 500 ; ms :every 10 ; ms :repeat 3 :singleton false)
schedule function takes two or three arguments, and also
name- the name of the job. If the given name is the same as the name of previously scheduled job in the application's runtime, the prior job will be unscheduled and the new job will be scheduled in its place. The name can be either a keyword or a string, but keywords will be converted to strings internally, so
:fooand ="foo"= will refer to the same job.
f- the zero argument function that will be invoked each time the job fires.
spec- the optional cron-style specification string if you are scheduling a cron-style job. It is an error to provide a spec along with any of the at options. See Cron Syntax.
options- options are specified as alternating key & value literals. Valid options are:
Option Default Description :at none, now if no
Specifies when the at job should start firing. Can be a java.util.Date or ms since epoch. Can't be specified with a
:in none Specifies when the at job should start firing, in ms from now. Can't be specified with a
:every none Specifies the delay interval between at job firings, in ms. If specified without a
:until, the job will fire indefinitely. Can't be specified with a
:repeat none Specifies the number of times an at job should repeat beyond its initial firing. Can't be specified with a
spec, and requires
:everyto be provided.
:until none Specifies when the at job should stop firing. Can be a java.util.Date or ms since epoch. Can't be specified with a
Marks the job as a singleton in a cluster. Singleton jobs will only execute on one node. If false, the job will execute on every node.
If you specify a job without a cron spec or any at options, it will fire once, immediately:
(ns my.ns (:require [immutant.jobs :as jobs])) (jobs/schedule "another-job" #(println "I'll fire right now, once."))
Job scheduling is dynamic, and can occur anytime during your application's lifecycle.
You can safely call
schedule multiple times with the same job
name - the named job will be rescheduled.
In case you need it, the org.quartz.JobExecutionContext instance is
immutant.jobs/*job-execution-context* before invoking
your job function.
The spec attribute should contain a crontab-like entry. This is similar to cron specifications used by Vixie cron, anacron and friends, but includes an additional field for specifying seconds. It is composed of 7 fields (6 are required):
|Seconds||Minutes||Hours||Day of Month||Month||Day of Week||Year|
|0-59||0-59||0-23||1-31||1-12 or JAN-DEC||1-7 or SUN-SAT||1970-2099 (optional)|
For several fields, you may denote subdivision by using the forward-slash (/) character. To execute a job every 5 minutes, */5 in the minutes field would specify this condition.
Spans may be indicated using the dash (-) character. To execute a job Monday through Friday, MON-FRI should be used in the day-of-week field.
Multiple values may be separated using the comma (,) character. The specification of 1,15 in the day-of-month field would result in the job firing on the 1st and 15th of each month.
Either day-of-month or day-of-week must be specified using the ? character, since specifying both is contradictory.
See the Quartz cron specification for additional details.
6.2.2. Job MBeans
Each job scheduled gets its own mbean under the
immutant.jobs namespace. This mbean can be used
to stop, start, and reschedule the job.
6.3. Unscheduling Jobs
Jobs can be unscheduled via the immutant.jobs/unschedule function:
(require '[immutant.jobs :as jobs]) (jobs/unschedule "my-job-name")
unschedule function requires one argument:
name- the name of a previously scheduled job.
If the given name resolves to an existing job, that job will be unscheduled and the call will
nil is returned.
Jobs are automatically unscheduled when your application is undeployed.