hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HADOOP-6939) Inconsistent lock ordering in AbstractDelegationTokenSecretManager
Date Fri, 03 Sep 2010 23:21:33 GMT

     [ https://issues.apache.org/jira/browse/HADOOP-6939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Todd Lipcon updated HADOOP-6939:

    Attachment: hadoop-6939.txt

Attached patch fixes the issue (verified before/after with a jcarder run of TestCheckPointForSecurityTokens)

> 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
>            Priority: Minor
>         Attachments: 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.

View raw message