You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Josh Elser (JIRA)" <ji...@apache.org> on 2019/05/14 15:38:00 UTC

[jira] [Resolved] (HBASE-22386) HBOSS: Limit depth that listing locks check for other locks

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

Josh Elser resolved HBASE-22386.
--------------------------------
       Resolution: Fixed
     Hadoop Flags: Reviewed
    Fix Version/s: hbase-filesystem-1.0.0-alpha1

> HBOSS: Limit depth that listing locks check for other locks
> -----------------------------------------------------------
>
>                 Key: HBASE-22386
>                 URL: https://issues.apache.org/jira/browse/HBASE-22386
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Sean Mackrory
>            Assignee: Sean Mackrory
>            Priority: Major
>             Fix For: hbase-filesystem-1.0.0-alpha1
>
>         Attachments: HBASE-22386.001.patch, HBASE-22386.002.patch
>
>
> treeWriteLock will check all the way up and down the tree for locks. This is more aggressive than it needs to be, and integration testing has shown that there's significant contention when listing tables, and this is one of numerous operations that doesn't need to recursively lock the whole subtree. There's actually a number of operations that only need to lock up or down 1 level only, so let's start with listing: non-recursive listings don't need to care about what's going on more than 1 level below them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)