[
https://issues.apache.org/jira/browse/MAPREDUCE-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12834665#action_12834665
]
Todd Lipcon commented on MAPREDUCE-1436:
----------------------------------------
Hi Matei,
I don't think this issue actually occurs in trunk - I'm speaking now about the
top issue from this issue involving finalizeJob. MAPREDUCE-870 refactored this
stuff, and finalizeJob therefore no longer has to go "upwards" to the scheduler
lock.
I turned on preemption and ran a couple of sleep jobs under jcarder, and it
didn't identify this issue either. Just to sanity check myself, I added a
synchronized (taskTrackerScheduler) { System.err.println("hi"); } in the
finalizeJob method, and reran the test. jcarder spit out the expected potential
deadlock just like you saw it.
I think, really, the JT was at fault here for inverting the lock heirarchy. It
no longer does this, so I think we're safe without this patch.
What do you think?
> Deadlock in preemption code in fair scheduler
> ---------------------------------------------
>
> Key: MAPREDUCE-1436
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-1436
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: contrib/fair-share
> Affects Versions: 0.21.0, 0.22.0
> Reporter: Matei Zaharia
> Assignee: Matei Zaharia
> Priority: Blocker
> Attachments: deadlock.png, mapreduce-1436-v2.patch,
> mapreduce-1436.patch
>
>
> In testing the fair scheduler with preemption, I found a deadlock between
> updatePreemptionVariables and some code in the JobTracker. This was found
> while testing a backport of the fair scheduler to Hadoop 0.20, but it looks
> like it could also happen in trunk and 0.21. Details are in a comment below.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
