Uploaded image for project: 'Hadoop Common'
  1. Hadoop Common
  2. HADOOP-6939

Inconsistent lock ordering in AbstractDelegationTokenSecretManager

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 0.22.0
    • Fix Version/s: 0.23.0
    • Component/s: None
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      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.

        Attachments

        1. lockorder.png
          51 kB
          Todd Lipcon
        2. hadoop-6939.txt
          1.0 kB
          Todd Lipcon
        3. HADOOP-6939.patch
          0.9 kB
          Tom White

          Activity

            People

            • Assignee:
              tlipcon Todd Lipcon
              Reporter:
              tlipcon Todd Lipcon
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: