[ https://issues.apache.org/jira/browse/HADOOP-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom White updated HADOOP-6939: ------------------------------ Resolution: Fixed Fix Version/s: 0.23.0 Status: Resolved (was: Patch Available) I've just committed this. Thanks Todd! (I re-ran the tests that failed for hudson and they all passed for me.) > Inconsistent lock ordering in AbstractDelegationTokenSecretManager > ------------------------------------------------------------------ > > Key: HADOOP-6939 > URL: https://issues.apache.org/jira/browse/HADOOP-6939 > Project: Hadoop Common > Issue Type: Bug > Affects Versions: 0.22.0 > Reporter: Todd Lipcon > Assignee: Todd Lipcon > Priority: Minor > Fix For: 0.23.0 > > Attachments: HADOOP-6939.patch, hadoop-6939.txt, lockorder.png > > > AbstractDelegationTokenSecretManager.startThreads() is synchronized, which > calls updateCurrentKey(), which calls logUpdateMasterKey. > logUpdateMasterKey's implementation for HDFS's manager calls > namesystem.logUpdateMasterKey() which is synchronized. Thus the lock order is > ADTSM -> FSN. In FSN.saveNamespace, though, it calls > DTSM.saveSecretManagerState(), so the lock order is FSN -> ADTSM. > I don't think this deadlock occurs in practice since saveNamespace won't > occur until after the ADTSM has started its threads, but should be fixed > anyway. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.