[
https://issues.apache.org/jira/browse/HADOOP-4149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amar Kamat updated HADOOP-4149:
-------------------------------
Attachment: HADOOP-4149-v1.7.patch
Attaching a patch the addresses Hemanth's concern.
1) Changed _STARTTIME_JOB_COMPARATOR_ to consider job-id
2) Removed unnecessary priority change in {{TestJobInProgressListener}}
3) {{TestCapacityScheduler}} now changes the start-time first and then the
priority to make sure that job1 is first in the list. Tests now also check for
the ordering apart from size.
Output of _test-patch_ on my box :
{code}
[exec] +1 overall.
[exec]
[exec] +1 @author. The patch does not contain any @author tags.
[exec]
[exec] +1 tests included. The patch appears to include 9 new or
modified tests.
[exec]
[exec] +1 javadoc. The javadoc tool did not generate any warning
messages.
[exec]
[exec] +1 javac. The applied patch does not increase the total number
of javac compiler warnings.
[exec]
[exec] +1 findbugs. The patch does not introduce any new Findbugs
warnings.
{code}
_ant test_ also passed on my box. Running through hudson.
> JobQueueJobInProgressListener.jobUpdated() might not work as expected
> ---------------------------------------------------------------------
>
> Key: HADOOP-4149
> URL: https://issues.apache.org/jira/browse/HADOOP-4149
> Project: Hadoop Core
> Issue Type: Bug
> Components: mapred
> Affects Versions: 0.19.0
> Reporter: Amar Kamat
> Assignee: Amar Kamat
> Priority: Blocker
> Fix For: 0.19.0
>
> Attachments: HADOOP-4149-v1.5.patch, HADOOP-4149-v1.7.patch
>
>
> {{JobQueueJobInProgressListener}} uses a {{TreeSet}} to store the sorted
> collection of {{JobInProgress}} objects. The comparator used to sort the JIPs
> follow the following order
> - priority (>=)
> - start time (<=)
> - job id [jt-identifier, job-index] (<=)
> If any JIP object is changed w.r.t priority or start-time, then the TreeSet
> will be inconsistent. Hence doing a delete might not work. Consider the
> following
> 1) jobs are submitted in the following order
> ||number||jobid||priority||
> |1|j1|NORMAL|
> |2|j2|LOW|
> |3|j3|NORMAL|
> 2) The sorted collection will be in the order : {{j1,j3,j2}}
> 3) If job3's priority is changed to LOW then the collection wont change but
> delete will bail out on j1 itself as the comparator will return a -ve number.
> TreeSet uses the comparator both for sorting and deleting. If i indicates
> the index in the collection and obj represents the object under
> consideration, then looks like TreeSet.remove(obj) follows something like :
> - continue to search if the compare(i, obj) is -ve
> - bail out if the compare(i, obj) is +ve
> - delete the obj of compare(i,obj) == 0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
