Continuing in Hydra land, one of the pinnacle objects is the Job. These jobs represent the construction of information from a source. Think of it as the worker, milling away to create the DataTree.
IJob
The IJob interface lays the foundation. It has many properties defining the characteristics of a job, such as start time, owner, priority, etc. It also has a few objects of note:
- Collection of JobParameters – name, value, and defaultValue for parameters to the job. An example of a JobParameter is job dependencies for data inputs (See listDependentJobs on the Spawn object.
- Collection of JobAlerts – configured alerts to send to users on the occurrence of specific events, caught by the scanAlerts function of the JobAlertRunner. The specific events are ERROR, COMPLETE, RUNTIME_EXCEEDED (job taking too long to complete), and REKICK_TIMEOUT (job did not restart when expected).
- Collection of JobTasks – Jobs are broken down into tasks, assigned to different hosts. The state of these tasks is retained for reporting errors, runs, files, and bytes. The Collection for the JobTasks on the Job class is synchronized for multi-threading.
- Collection of JobCommands – These are command encapsulations that run before each task runs on minions. Requirements are available for CPU, memory, and IO.
Usage
You’ll see jobs referenced in Spawn, which oversees the execution of them across the cluster. They are created and maintained, and also re-kicked within the JobRekickTask.