alirezazamani commented on a change in pull request #1006:
URL: https://github.com/apache/helix/pull/1006#discussion_r426940749
##########
File path: helix-core/src/main/java/org/apache/helix/task/RuntimeJobDag.java
##########
@@ -145,9 +145,21 @@ public boolean finishJob(String job) {
String.format("Job: %s has either finished already, never been
scheduled, or been removed from DAG", job));
}
// Add finished job's successors to ready-list
+
+ // If it is a jobQueue, there should be a check to make sure that the a
job has not been added
+ // to the _readyJobList multiple times. This check is necessary because
once the controller
+ // switch happens, the _readyJobList and _inflightJobList will be created
from scratch. In this
+ // case, since there might be many jobs that have been finished before, we
do not want to have a
+ // job several times to the _readyJobList. If _readyJobList has multiple
instances of the same
+ // job, it can compromise the functionality of the parallel jobs.
Review comment:
It is very hard to explain. I will do my best to explain it here. (If it
is still not clear, I suggest you to just run the test I added to this PR and
it will be very clear to you.)
Explanation:
Here is the _readyJobList contents after the controller switch in my test
(without this fix):
> [testQueueParallelJobs_JOB0, testQueueParallelJobs_JOB1,
testQueueParallelJobs_JOB2]
> [testQueueParallelJobs_JOB1, testQueueParallelJobs_JOB2,
testQueueParallelJobs_JOB1]
> [testQueueParallelJobs_JOB2, testQueueParallelJobs_JOB1,
testQueueParallelJobs_JOB2]
> [testQueueParallelJobs_JOB1, testQueueParallelJobs_JOB2,
testQueueParallelJobs_JOB3]
> [testQueueParallelJobs_JOB2, testQueueParallelJobs_JOB3,
testQueueParallelJobs_JOB2]
> [testQueueParallelJobs_JOB3, testQueueParallelJobs_JOB2,
testQueueParallelJobs_JOB3]
> [testQueueParallelJobs_JOB2, testQueueParallelJobs_JOB3,
testQueueParallelJobs_JOB4]
> [testQueueParallelJobs_JOB3, testQueueParallelJobs_JOB4,
testQueueParallelJobs_JOB3]
> [testQueueParallelJobs_JOB4, testQueueParallelJobs_JOB3,
testQueueParallelJobs_JOB4]
> [testQueueParallelJobs_JOB3, testQueueParallelJobs_JOB4]
> [testQueueParallelJobs_JOB4, testQueueParallelJobs_JOB4]
> [testQueueParallelJobs_JOB4]
> [testQueueParallelJobs_JOB5]
> [testQueueParallelJobs_JOB6]
>
We end up having jut JOB4 in the DAG and the reason is because once each job
is finished, we add new job to the _readyList (_readyList is updated in
finishJob method). If there is only one Job in the _readyList, we will wait
until 4 is finished and add JOB5 and so on. In this case, we will not run the
whole queue in parallel.
Also interesting to note here that even before controller swicth here is
_readyList which is also wrong and we see two JOBs with the same name in the
queue. However, this is not as critical as the the one I explained above:
> [testQueueParallelJobs_JOB0, testQueueParallelJobs_JOB1]
> [testQueueParallelJobs_JOB1]
> [testQueueParallelJobs_JOB0, testQueueParallelJobs_JOB1,
testQueueParallelJobs_JOB2]
> [testQueueParallelJobs_JOB1, testQueueParallelJobs_JOB2]
> [testQueueParallelJobs_JOB2]
> [testQueueParallelJobs_JOB3, testQueueParallelJobs_JOB3]
> [testQueueParallelJobs_JOB3]
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
