Registry Jobs are processes designed to be run asynchronously, usually via cron, 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.
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.
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 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.