[ 
https://issues.apache.org/jira/browse/HBASE-22386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836412#comment-16836412
 ] 

Sean Mackrory commented on HBASE-22386:
---------------------------------------

Oh that's embarassing, I don't know how I missed that - those 2 empty strings 
just aren't supposed to be there. Also added some @VisibleForTesting 
annotations where needed in the .002. patch.

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

Reply via email to