[ https://issues.apache.org/jira/browse/HBASE-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020859#comment-13020859 ]
Ted Yu commented on HBASE-3777: ------------------------------- I see TestHFileOutputFormat timeout: {code} "main" prio=5 tid=101801000 nid=0x100601000 waiting on condition [1005ff000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at org.apache.hadoop.hbase.client.HBaseAdmin.disableTable(HBaseAdmin.java:543) at org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat.doIncrementalLoadTest(TestHFileOutputFormat.java:352) at org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat.testMRIncrementalLoadWithSplit(TestHFileOutputFormat.java:163) {code} Another test failure was: {code} ------------------------------------------------------------------------------- Test set: org.apache.hadoop.hbase.replication.TestReplication ------------------------------------------------------------------------------- Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 110.1 sec <<< FAILURE! testVerifyRepJob(org.apache.hadoop.hbase.replication.TestReplication) Time elapsed: 8.15 sec <<< FAILURE! java.lang.AssertionError: expected:<0> but was:<100> at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.failNotEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:126) at org.junit.Assert.assertEquals(Assert.java:470) at org.junit.Assert.assertEquals(Assert.java:454) at org.apache.hadoop.hbase.replication.TestReplication.testVerifyRepJob(TestReplication.java:510) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) {code} > Redefine Identity Of HBase Configuration > ---------------------------------------- > > Key: HBASE-3777 > URL: https://issues.apache.org/jira/browse/HBASE-3777 > Project: HBase > Issue Type: Improvement > Components: client, ipc > Affects Versions: 0.90.2 > Reporter: Karthick Sankarachary > Assignee: Karthick Sankarachary > Priority: Minor > Fix For: 0.92.0 > > Attachments: HBASE-3777-V2.patch, HBASE-3777.patch > > > Judging from the javadoc in {{HConnectionManager}}, sharing connections > across multiple clients going to the same cluster is supposedly a good thing. > However, the fact that there is a one-to-one mapping between a configuration > and connection instance, kind of works against that goal. Specifically, when > you create {{HTable}} instances using a given {{Configuration}} instance and > a copy thereof, we end up with two distinct {{HConnection}} instances under > the covers. Is this really expected behavior, especially given that the > configuration instance gets cloned a lot? > Here, I'd like to play devil's advocate and propose that we "deep-compare" > {{HBaseConfiguration}} instances, so that multiple {{HBaseConfiguration}} > instances that have the same properties map to the same {{HConnection}} > instance. In case one is "concerned that a single {{HConnection}} is > insufficient for sharing amongst clients", to quote the javadoc, then one > should be able to mark a given {{HBaseConfiguration}} instance as being > "uniquely identifiable". > Note that "sharing connections makes clean up of {{HConnection}} instances a > little awkward", unless of course, you apply the change described in > HBASE-3766. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira