[
https://issues.apache.org/jira/browse/HBASE-22386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16839562#comment-16839562
]
Josh Elser commented on HBASE-22386:
------------------------------------
If I force ipv4 instead of ipv6, the unit tests pass with this change. I think
what's happening is that I just don't have the ipv6 routing set up, ZK tries to
use that, and the tests don't wait for the curator ZK client to become
connected before tryign to use it. This results in a ConnectionLoss, something
like:
{noformat}
[ERROR]
testConcatMissingTarget(org.apache.hadoop.hbase.oss.contract.TestHBOSSContractConcat)
Time elapsed: 0.117 s <<< ERROR!
java.io.IOException: Failed to get FS
at
org.apache.hadoop.hbase.oss.contract.HBOSSContract.getTestFileSystem(HBOSSContract.java:73)
at
org.apache.hadoop.fs.contract.AbstractFSContractTestBase.setup(AbstractFSContractTestBase.java:181)
at
org.apache.hadoop.fs.contract.AbstractContractConcatTest.setup(AbstractContractConcatTest.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
at
org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: Unable to initialize root znodes
at
org.apache.hadoop.hbase.oss.sync.ZKTreeLockManager.initialize(ZKTreeLockManager.java:95)
at org.apache.hadoop.hbase.oss.sync.TreeLockManager.get(TreeLockManager.java:72)
at
org.apache.hadoop.hbase.oss.HBaseObjectStoreSemantics.initialize(HBaseObjectStoreSemantics.java:122)
at org.apache.hadoop.hbase.oss.TestUtils.getFileSystem(TestUtils.java:97)
at
org.apache.hadoop.hbase.oss.contract.HBOSSContract.getTestFileSystem(HBOSSContract.java:69)
... 16 more
Caused by: org.apache.zookeeper.KeeperException$ConnectionLossException:
KeeperErrorCode = ConnectionLoss for /hboss
at org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1102)
at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1130)
at org.apache.curator.utils.ZKPaths.mkdirs(ZKPaths.java:274)
at org.apache.curator.utils.ZKPaths.mkdirs(ZKPaths.java:221)
at
org.apache.hadoop.hbase.oss.sync.ZKTreeLockManager.initialize(ZKTreeLockManager.java:93)
... 20 more{noformat}
I'll open up another Jira issue to track how we want to handle IPv6 rather than
convolute this one.
+1 on this patch. I would like to know understand better what the write locking
concerns are for the future :)
> 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)
