About Registry Jobs
Registry Jobs are processes designed to be run asynchronously, usually via cron, and intended to handle large operations not suitable for a single web transaction.
Jobs are processed via the Job Command, and a Job can be run synchronously (from the command line), or it can be scheduled for asynchronous processing (via cron). When Jobs are run asynchronously, Job Command will process all queued Jobs for a given CO sequentially in the order they were queued. It is not currently possible to prioritize some Jobs over others.
Some Jobs can also be scheduled from the UI, see the plugin specific documentation for details.
Job Status
When a Job is first registered, it is placed in Queued
status. When a queue runner is ready to process a new Job, or when a Job is processed synchronously from the command line, the job moves to Assigned
status, and the assigned host and PID are recorded. When the Plugin for the Job is invoked, the Job enters InProgress
status. From there, the Job will be marked Complete
or Failed
as appropriate.
Canceling Jobs
A Job may be canceled if it is in Assigned
, InProgress
, or Queued
state by viewing the Job artifact and clicking Cancel. If the Job is in Queued
state, the cancelation is immediate. Otherwise, it is up to the invoked Plugin to determine when to actually stop processing.
Since the Job Command creates child processes (via fork()
), it is possible for a system administrator to terminate an unresponsive or uncooperative Job by logging into the Assigned Host and terminating the Assigned Process ID.
Registry Job History
Registry Job history is recorded in tables that can be viewed via the web interface. Currently, only CO Administrators may view Registry job history.
High level job status is maintained in the jobs table, including status about the job when it is queued, started, and finished. Specific transaction or task status is maintained in the job_history_records table, and these records may be linked to a Person or External Identity record. These records may be viewed from the appropriate person canvas, for authorized viewers.
It is up to each job type to determine what sort of detailed records to maintain.
Currently, Job History will also be rendered to the trace log. This behavior is subject to change in a future release.
See Also
- Registry Job Command
- Available Job Plugins
- New Registry Setup
- Job API v2
- JobHistoryRecord API v2
- Registry Table: job_history_records
- Registry Table: jobs
Changes From Earlier Versions
As of Registry v5.0.0
- The Job Queue may be processed in parallel.
- The Job Queue may be processed from multiple hosts.