Uploaded image for project: 'HBase'
  1. HBase
  2. HBASE-16144

Replication queue's lock will live forever if RS acquiring the lock has died prematurely

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 1.3.0, 1.4.0, 1.2.2, 0.98.20, 1.1.6, 2.0.0
    • 1.3.0, 1.1.6, 1.2.3, 2.0.0
    • None
    • None
    • Reviewed
    • If zk based replication queue is used and useMulti is false, we will schedule a chore to clean up the orphan replication queue lock on zk.

    Description

      In default, we will use multi operation when we claimQueues from ZK. But if we set hbase.zookeeper.useMulti=false, we will add a lock first, then copy nodes, finally clean old queue and the lock.

      However, if the RS acquiring the lock crash before claimQueues done, the lock will always be there and other RS can never claim the queue.

      Attachments

        1. HBASE-16144-0.98.v1.patch
          14 kB
          Phil Yang
        2. HBASE-16144-branch-1.1-v1.patch
          16 kB
          Phil Yang
        3. HBASE-16144-branch-1.1-v2.patch
          14 kB
          Phil Yang
        4. HBASE-16144-branch-1-v1.patch
          16 kB
          Phil Yang
        5. HBASE-16144-branch-1-v2.patch
          14 kB
          Phil Yang
        6. HBASE-16144-v1.patch
          15 kB
          Phil Yang
        7. HBASE-16144-v2.patch
          16 kB
          Phil Yang
        8. HBASE-16144-v3.patch
          16 kB
          Phil Yang
        9. HBASE-16144-v4.patch
          16 kB
          Phil Yang
        10. HBASE-16144-v5.patch
          16 kB
          Phil Yang
        11. HBASE-16144-v6.patch
          16 kB
          Duo Zhang
        12. HBASE-16144-v6.patch
          16 kB
          Phil Yang

        Activity

          People

            yangzhe1991 Phil Yang
            yangzhe1991 Phil Yang
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: