[
https://issues.apache.org/jira/browse/HBASE-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026724#comment-13026724
]
jirapos...@reviews.apache.org commented on HBASE-3777:
------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/643/
-----------------------------------------------------------
(Updated 2011-04-28 22:01:18.165256)
Review request for hbase and Ted Yu.
Changes
-------
The V8 version of the diff addresses Todd's concerns around leaks in the event
of exceptions. In short, it wraps all (method-level) blocks that access the
connection around the HCM#execute method, which takes care of acquiring and
closing the connection. Specifically, exceptions thrown by close will be
swallowed if (and only if) the block itself throws one. There were no
regressions, AFAIK, although the TestHRegionLocation and TestCatalogTracker
tests did fail.
Summary
-------
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".
This addresses bug HBASE-3777.
https://issues.apache.org/jira/browse/HBASE-3777
Diffs (updated)
-----
src/main/java/org/apache/hadoop/hbase/HConstants.java 0911375
src/main/java/org/apache/hadoop/hbase/catalog/CatalogTracker.java feed777
src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java fa7448b
src/main/java/org/apache/hadoop/hbase/client/HConnection.java 1beedaf
src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java ded51c8
src/main/java/org/apache/hadoop/hbase/client/HTable.java 46bac9f
src/main/java/org/apache/hadoop/hbase/client/HTablePool.java 88827a8
src/main/java/org/apache/hadoop/hbase/client/MetaScanner.java 26d0b31
src/main/java/org/apache/hadoop/hbase/client/replication/ReplicationAdmin.java
d76e333
src/main/java/org/apache/hadoop/hbase/mapred/TableOutputFormat.java 80284bb
src/main/java/org/apache/hadoop/hbase/mapreduce/TableOutputFormat.java
05d9395
src/main/java/org/apache/hadoop/hbase/mapreduce/replication/VerifyReplication.java
ed88bfa
src/main/java/org/apache/hadoop/hbase/master/HMaster.java 58c9153
src/main/java/org/apache/hadoop/hbase/master/ServerManager.java 64c14df
src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java d211b53
src/main/java/org/apache/hadoop/hbase/replication/master/ReplicationLogCleaner.java
133da33
src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSource.java
fc71f03
src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java 1c1d94b
src/main/java/org/apache/hadoop/hbase/util/HBaseFsckRepair.java 39f3af2
src/main/java/org/apache/hadoop/hbase/util/HMerge.java c447287
src/main/java/org/apache/hadoop/hbase/zookeeper/ZKUtil.java a4def94
src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWatcher.java dc471c4
src/test/java/org/apache/hadoop/hbase/TestRegionRebalancing.java 75613b8
src/test/java/org/apache/hadoop/hbase/catalog/TestCatalogTracker.java 126d9af
src/test/java/org/apache/hadoop/hbase/catalog/TestMetaReaderEditor.java
18e647e
src/test/java/org/apache/hadoop/hbase/client/TestHCM.java 5d71d75
src/test/java/org/apache/hadoop/hbase/mapreduce/TestTableMapReduce.java
624f4a8
src/test/java/org/apache/hadoop/hbase/master/TestClockSkewDetection.java
752e12b
src/test/java/org/apache/hadoop/hbase/util/TestMergeTable.java 8992dbb
Diff: https://reviews.apache.org/r/643/diff
Testing
-------
mvn test
Thanks,
Karthick
> 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: 3777-TOF.patch, HBASE-3777-V2.patch,
> HBASE-3777-V3.patch, HBASE-3777-V4.patch, HBASE-3777-V6.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
