[
https://issues.apache.org/jira/browse/HBASE-22386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837414#comment-16837414
]
Sean Mackrory commented on HBASE-22386:
---------------------------------------
Don't think so, if I do this in my terminal I get pretty green lines that say
SUCCESS
{code}(
cd $(mktemp --directory)
git clone https://github.com/apache/hbase-filesystem.git
cd hbase-filesystem
curl
https://issues.apache.org/jira/secure/attachment/12968306/HBASE-22386.002.patch
| patch -p1
mvn verify
){code}
> 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)
