Hi,
I am wondering if there is perhaps a slight anomaly in the
conceptualizations of the Job Queue and Triggered Jobs. Bear with me on
this long email...
The Job Queue is a global entity in that a job is placed on the one and
only one queue. The Triggers, on the other hand, are handled per job, so in
that sense they are local to the parent job.
This difference causes a problem with respect to implementing job
priorities. A job priority is also global in that, for a particular job,
the priority number is absolute across all jobs.
The problem occurs when the queue is priority sorted. The priority position
of a job in the queue depends on the current jobs in the queue at that
instant but any triggered jobs aren't there ... yet. There is a potential
that a triggered job has a higher priority than any other job currently in
the queue, but it is not taken into consideration simply because it's not
there yet. For example:
The queue currently contains the following:
job100 (has two triggered jobs job1 and job2)
job101
In this case, job100 ends, and since job101 is, at that instant the highest
priority job in the queue, it is started. But a split second later, job1
and job2 are put on the queue:
job101 -- executing
job1
job2
So even though there were higher priority jobs that should have been run,
the executor is running the lowest priority job in the system.
Compare all of this to a slightly different concept of triggered jobs: all
triggered jobs are -- tentatively -- put on the queue when the parent is
put on it. This allows the job priorities to be accurately sorted. For
example:
job100
job1 (parent=job100, tentative)
job2 (parent=job100, tentative)
job101
When job100 ends and was successful, then job1 and job2 are converted:
job1
job2
job101
If job100 ends and has failed, then job1 and job2 are removed:
job101
Jobs currently in the executors are currently excluded from job priority
calculations as well. So again there is a slight anomaly in the way a job's
conceptualization changes when it enters an executor.
Considering all jobs in the queue, in the executors and potentially
triggered in the same conceptual way, makes for some very useful
capabilities.
One possibility is to remove redundant, triggered jobs in the queue, for
example a "packager" job that is run after one, or more, of a set of
subsystem jobs. Say there are 3 subsystems A, B, C and there is a master
job that packages all three into one master package.
jobSubsysA (priority=100) triggers jobPackager (priority=101)
jobSubsysB (priority=100) triggers jobPackager (priority=101)
jobSubsysC (priority=100) triggers jobPackager (priority=101)
Kicking off jobsubsysA, jobSubsysB and jobSubsysC would make the queue look
like this:
jobSubsysA (priority=100)
jobSubsysB (priority=100)
jobSubsysC (priority=100)
jobPackager (priority=101 parent=jobSubsysA, tentative)
jobPackager (priority=101 parent=jobSubsysB, tentative)
jobPackager (priority=101 parent=jobSubsysC, tentative)
and there is a potential now to implement redundant job removal:
jobSubsysA (priority=100)
jobSubsysB (priority=100)
jobSubsysC (priority=100)
jobPackager (priority=101 parent=jobSubsysA jobSubsysB jobSubsysC,
tentative)
If all of A, B and C end and build successfully, the jobPackager is run
only once.
What do you think?
John
