hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom White (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HADOOP-6939) Inconsistent lock ordering in AbstractDelegationTokenSecretManager
Date Tue, 30 Nov 2010 00:17:11 GMT

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

Tom White updated HADOOP-6939:

    Attachment: HADOOP-6939.patch

Fixed patch.

> 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
>         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.

View raw message