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

Inconsistent lock ordering in AbstractDelegationTokenSecretManager

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • 0.22.0
    • 0.23.0
    • None
    • None
    • 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
          Thomas White

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: