is for performing work asynchronously outside of the request flow.
The job is either:
- A recurring task, eg updating a 5 min ticker
- A one-off task, such as sending emails or updating a leger or cashe
is optional not enabled by default.
To activate add
module.jobs to the app.conf file:
module.jobs = github.com/revel/modules/jobs
Additionally, in order to access the job monitoring page, you will need to add
/@jobs to the
conf/routes to browse to url:
// url = /@jobs module:jobs
There are some configuration settings that place some limitations job and its run, explained below with default values:
jobs.pool = 10- The number of jobs allowed to run simultaneously/concurrently
jobs.selfconcurrent = false- Allow a job to run only if previous instances are done
jobs.acceptproxyaddress = false- Accept
X-Forwarded-Forheader value (which is spoofable) to allow or deny status page access
To run a task on application startup, use
revel.OnAppStart() to register a function.
Revel runs these tasks serially, before starting the server. Note that this
functionality does not actually use the jobs module, but it can be used to
submit a job for execution that doesn’t block server startup.
Jobs may be scheduled to run on any schedule. There are two options for expressing the schedule:
- A cron specification
- A fixed interval
Jobs are generally registered using the
revel.OnAppStart() hook, but they may be
registered at any later time as well.
Here are some examples:
Here is an example named cron schedule, in an
cron.workhours_15m = 0 */15 9-17 ? * MON-FRI
Use the named schedule by referencing it anywhere you would have used a cron spec.
Sometimes it is necessary to do something in response to a user action. In these cases, the jobs module allows you to submit a job to be run a single time.
The only control offered is how long to wait until the job should be run.
It is possible to register a
func() as a job by wrapping it in the
type. For example:
The jobs module provides a status page (
/@jobs url) that shows:
- a list of the scheduled jobs it knows about
- the current status; IDLE or RUNNING
- the previous and next run times
Constrained pool size
It is possible to configure the job module to limit the number of jobs that are allowed to run at the same time. This allows the developer to restrict the resources that could be potentially in use by asynchronous jobs – typically interactive responsiveness is valued above asynchronous processing. When a pool is full of running jobs, new jobs block to wait for running jobs to complete.
Future areas for development
- Allow access to the job status page with HTTP Basic Authentication credentials
- Allow administrators to run scheduled jobs interactively from the status page
- Provide more visibility into the job runner, e.g. the pool size, the job queue length, etc.