[
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
