[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102569#comment-14102569
]
stack commented on HBASE-11657:
---
bq. For RegionLocations, we may need an immutable version.
Sounds good.
Looking at patch, would I ever have to clean up a RegionLocator... call close
on it when done? Otherwise +1
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch,
HBASE_11657_v5.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14102613#comment-14102613
]
stack commented on HBASE-11657:
---
+1 on v6 (Waiting on Pope @enis to give his blessing before commit)
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch,
HBASE_11657_v5.patch, HBASE_11657_v6.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103005#comment-14103005
]
Enis Soztutar commented on HBASE-11657:
---
+1. May the force be with you.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch,
HBASE_11657_v5.patch, HBASE_11657_v6.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103145#comment-14103145
]
Hudson commented on HBASE-11657:
FAILURE: Integrated in HBase-1.0 #113 (See
[https://builds.apache.org/job/HBase-1.0/113/])
HBASE-11657 Put HTable region methods in an interface (Carter Page) (stack: rev
acf69411c91bc2a813a99db2f948f7066174)
* hbase-client/src/main/java/org/apache/hadoop/hbase/client/HConnection.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/HRegionLocation.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionManager.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/client/HConnectionTestingUtility.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/client/CoprocessorHConnection.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/client/RegionLocator.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionAdapter.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0, 2.0.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch,
HBASE_11657_v5.patch, HBASE_11657_v6.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103220#comment-14103220
]
Hudson commented on HBASE-11657:
SUCCESS: Integrated in HBase-TRUNK #5412 (See
[https://builds.apache.org/job/HBase-TRUNK/5412/])
HBASE-11657 Put HTable region methods in an interface (Carter Page) (stack: rev
c08f850d405445b9af4d3a401ce23c8626d07975)
* hbase-client/src/main/java/org/apache/hadoop/hbase/client/RegionLocator.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/client/CoprocessorHConnection.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/HRegionLocation.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/client/HConnection.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/client/HConnectionTestingUtility.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionManager.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionAdapter.java
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0, 2.0.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch,
HBASE_11657_v5.patch, HBASE_11657_v6.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100876#comment-14100876
]
Carter commented on HBASE-11657:
That would certainly solve the problem with {{TableInputFormatBase}}. We
should also probably add a _getTableName_ method to {{RegionLocator}},
regardless. Then passing the RL interface instead of a raw HTable object would
provide everything that it needs for sharding the MR.
A more philosophical question is, why is {{HRegionLocation}}
InterfaceAudience.Private to begin with? It is a POJO that wraps
{{HRegionInfo}} (InterfaceAudience.Public), {{ServerName}}
(InterfaceAudience.Public), and _seqNum_ (an immutable long). It seems to me
that either the internal fields should be private too, or HRegionLocation
should be public. Unless there is some correlation of that information that
shouldn't be exposed. Thoughts, [~stack], [~ndimiduk], [~enis]?
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101086#comment-14101086
]
Enis Soztutar commented on HBASE-11657:
---
I've made HRL private in an earlier patch that introduced RegionLocations
class. The idea was to make regions transparent to users because they can
change, not specific to HRL per se. With the introduction of RegionLocations
and HBASE-10070 work, there can be more than one location for a region together
with different replica_ids associated with regions. I did not want to expose
those as the public API, but we can revisit that decision if we want.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101189#comment-14101189
]
Carter commented on HBASE-11657:
I mainly wanted to make sure that the same person who made HRL private is okay
with whatever we come up with for this interface. Since you are one and the
same person, I am less concerned. ;-)
I double-checked and there is actually still a problem with the (byte[]/byte[])
- listservernames. In short TabletInputFormatBase wants the following from
the HTable that is being passed to it:
# The hostname and port of the regionserver for a row (handled by ServerName)
# The name of the table (we can add getTableName to RegionLocator)
# The region name itself, which it uses to lookup the region size in the
RegionSizeCalculator (handled by HRegionInfo)
I see the following alternatives:
* Make HRL public. It contains ServerName and HRegionInfo, which are both
required by the current implementation of TableInputFormatBase.
* Return ServerName and region name in some new POJO
* Find a new way to do what TableInputFormatBase wants to accomplish
Sorry to open up this can of worms, but that's part of the fun of retrofitting
an interface.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101532#comment-14101532
]
Enis Soztutar commented on HBASE-11657:
---
bq. Sorry to open up this can of worms, but that's part of the fun of
retrofitting an interface.
Agreed. It is good exercise in API design.
bq. Make HRL public. It contains ServerName and HRegionInfo, which are both
required by the current implementation of TableInputFormatBase.
I think this should be ok.
bq. Return ServerName and region name in some new POJO
What we want to hide is not HRL per se, but the region name concept. In this
case, making HRL public seems better.
bq. Find a new way to do what TableInputFormatBase wants to accomplish
I think RegionSizeCalculator should be made to work over ranges similar to the
MR API, but it can be another jira. What I am afraid more is whether there
maybe more users of HRL (other than MR) that we do not know about. Since
InterfaceAudience is fairly recent and it is not a hard check, there may be a
lot of users depending on it. If this is the case (which I honestly do not
know), then we should better made HRL public and be done with it. For
RegionLocations, we may need an immutable version.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14096609#comment-14096609
]
stack commented on HBASE-11657:
---
Yeah, we've been trying to shutdown notions of 'region' showing through in API.
We don't want to break API for 1.0. Mark new Interface Private audience too
instead of evolving as it is currently (IIRC)?
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14096975#comment-14096975
]
Carter commented on HBASE-11657:
How should the interfaces and MapReduce play together? I know certain classes
like TableInputFormatBase look at HRegionLocation. If that's not something
that should still be exposed, then to maintain appropriate encapsulation of
HBase from MR we'll have to explore an alternative. Any ideas?
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14097209#comment-14097209
]
Nick Dimiduk commented on HBASE-11657:
--
The MapReduce classes are considered internal API. A user doesn't need to
know where a region lives in order to submit a MR job.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14097215#comment-14097215
]
Nick Dimiduk commented on HBASE-11657:
--
bq. Should RegionLocator extend Closeable?
I think so yes. This is consistent with Admin also being closable, despite
being retrieved from the closable HConnection.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14097731#comment-14097731
]
Carter commented on HBASE-11657:
I'll add Closeable to the interface, makes sense.
While the user doesn't need to know where a region lives in order to submit an
MR job, it currently needs the user to pass the means to get that region
location by means of {{TableInputFormatBase#setHTable(HTable)}}. This prompts
two questions:
# Doesn't the existence of this public method break the interface abstraction
that v1 is trying to establish?
# If so, what replaces it?
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14097745#comment-14097745
]
Enis Soztutar commented on HBASE-11657:
---
bq. How should the interfaces and MapReduce play together? I know certain
classes like TableInputFormatBase look at HRegionLocation. If that's not
something that should still be exposed, then to maintain appropriate
encapsulation of HBase from MR we'll have to explore an alternative
For MR, we usually have one input split == one region, however, the region
boundaries can always change after they are obtained or the job starts.
However, for MR and other partitioning purposes, I think we will want to keep
the getStartEndKeys() API that is byte[] ranges. Maybe we can couple that with
a
map of
byte[] - byte[] range - list of locations (ServerNames)
API which will be our public facing partitioning / location API. We can keep
HRL private this way.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14095812#comment-14095812
]
Carter commented on HBASE-11657:
The three test failures seem unrelated to the patch. I don't get the first two
failures on the patch against the latest master, and the TestRegionRebalancing
appears flaky.
Anything else we need on this patch?
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14096178#comment-14096178
]
Enis Soztutar commented on HBASE-11657:
---
A couple of comments:
- RegionLocator - I like the name.
- Should RegionLocator extend Closeable?
- clearRegionCache() seems like an overkill for exposing.
- HRegionLocation and RegionLocations have been made InterfaceAudience.Private
in 0.99. The main idea was to make start-end keys are byte[] ranges the main
public API, but not the regions / region locations themselves. I know that some
advanced users have been using HRL for some time, but I am not keen to make it
a public API. What do you guys think?
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14094194#comment-14094194
]
Hadoop QA commented on HBASE-11657:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12661013/HBASE_11657_v4.patch
against trunk revision .
ATTACHMENT ID: 12661013
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.TestEndToEndSplitTransaction
org.apache.hadoop.hbase.security.visibility.TestVisibilityLabelsWithDeletes
org.apache.hadoop.hbase.TestRegionRebalancing
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/10400//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10400//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10400//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10400//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10400//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10400//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10400//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10400//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10400//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10400//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10400//console
This message is automatically generated.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092970#comment-14092970
]
Carter commented on HBASE-11657:
Please take another look.
For the managed connection check, I'm just following the same pattern for the
#getTable(TableName) factory method to keep it consistent.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14093602#comment-14093602
]
Enis Soztutar commented on HBASE-11657:
---
Carter, I really like this jira. Let me take a deeper look at the patch and the
rest of the comments.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch, HBASE_11657_v4.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091679#comment-14091679
]
Hadoop QA commented on HBASE-11657:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12660796/HBASE_11657_v3.patch
against trunk revision .
ATTACHMENT ID: 12660796
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/10367//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10367//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10367//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10367//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10367//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10367//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10367//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10367//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10367//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10367//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10367//console
This message is automatically generated.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091639#comment-14091639
]
stack commented on HBASE-11657:
---
It makes sense to me going to a RegionLocator Interface to obtain
(H)RegionLocation s.
The Interface seems a little unhinged not having methods that specify the
associated table but hanging the Interface off HTable takes care of that.
The '@since 0.99' is good.
The other methods are an awkward fit in this new Interface -- getStartKeys,
etc. -- but they are bastard children anyways and rather than do a StartKeys
interface, lets let them hang in here for now at least.
In HConnection it should be getRegionLocator rather than getRegionLocation?
nit: 'of teh ' should be 'of the'
Whats this mean boss: RegionLocator needs to be unmanaged... We have to
close or return the locator?
Otherwise patch is great. +1 I can fix above minors on commit if you'd like,
just say.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch, HBASE_11657_v3.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14087792#comment-14087792
]
Hadoop QA commented on HBASE-11657:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12660139/HBASE_11657_v3.patch
against trunk revision .
ATTACHMENT ID: 12660139
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.master.TestRestartCluster
org.apache.hadoop.hbase.client.TestReplicasClient
org.apache.hadoop.hbase.regionserver.TestRegionReplicas
org.apache.hadoop.hbase.master.TestMasterOperationsForRegionReplicas
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/10315//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10315//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10315//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10315//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10315//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10315//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10315//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10315//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10315//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10315//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10315//console
This message is automatically generated.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch,
HBASE_11657_v3.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14086383#comment-14086383
]
Hadoop QA commented on HBASE-11657:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12659895/HBASE_11657.patch
against trunk revision .
ATTACHMENT ID: 12659895
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.procedure.TestProcedureManager
org.apache.hadoop.hbase.ipc.TestIPC
org.apache.hadoop.hbase.master.TestClockSkewDetection
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/10299//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10299//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10299//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10299//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10299//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10299//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10299//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10299//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10299//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10299//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10299//console
This message is automatically generated.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14086430#comment-14086430
]
Carter commented on HBASE-11657:
No deltas between tests I ran on master and the patch.
No new test since this is simply an interface. I'll refactor other tests to
use the interface in the future.
I have a general question for the group. Why is _getRegionLocation_ okay, but
this one is deprecated?
{code}
@Deprecated
public ListHRegionLocation getRegionsInRange(final byte [] startKey, final
byte [] endKey, final boolean reload)
{code}
Does this seem like an appropriate method now in RegionLocator? If this
remains deprecated, what's the correct alternative for clients that use it?
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14086617#comment-14086617
]
Mikhail Antonov commented on HBASE-11657:
-
Thanks [~carterpage] - few comments:
- copyright notice to RegionLocator doesn't look right, also missing class
javadoc and audience annotation (private?)
- instead having 2 getRegionLocation methods, one of which always use cached
info, and the other one - optionally, seems like we can just have 1 method,
which take row key and boolean - reloadCache or not?
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14086624#comment-14086624
]
stack commented on HBASE-11657:
---
[~mantonov] We have to preserve current api if we are to commit this patch to
branch-1. FYI.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14086653#comment-14086653
]
Mikhail Antonov commented on HBASE-11657:
-
@stack yeah, I was just thinking as we're adding new interface and making
HTable extend it, may be for API compatibility it'd suffice if we just have one
method with (rowkey, whetherToReloadCache) in the RegionLocator interface, and
in HTable still use both version, but the one without this boolean flag won't
have Override annotation? What do you think? Maybe I'm missing something.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14086790#comment-14086790
]
Carter commented on HBASE-11657:
Not sure I agree on having only one method. I agree with the general principle
of reducing methods. For example, overloads that take String, byte[], and
TableName for a table name are messy and not helpful.
In this case, however, I assume users will want to use
getRegionLocation(byte[]) the majority of time, and forcing a reload would be
less frequent. I think it makes it simpler for the user when common defaults
are hidden, hence providing the two methods -- one for most cases and one for
explicit behavior overrides.
If however, users typically call getRegionLocation(byte[], boolean) more often,
then I agree it would make sense to only have that one in the interface, but
I'm guessing that's not the case.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14086853#comment-14086853
]
Mikhail Antonov commented on HBASE-11657:
-
Yes, the reasoning about most used vs. rarely used method makes sense. Do you
think it makes sense to mark the interface less carved in stone as {public,
stable}? May be public, evolving or unstable?
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14086942#comment-14086942
]
Hadoop QA commented on HBASE-11657:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12659957/HBASE_11657_v2.patch
against trunk revision .
ATTACHMENT ID: 12659957
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.TestRegionReplicas
org.apache.hadoop.hbase.mapreduce.TestTableSnapshotInputFormat
org.apache.hadoop.hbase.master.TestRestartCluster
org.apache.hadoop.hbase.client.TestReplicasClient
org.apache.hadoop.hbase.TestIOFencing
org.apache.hadoop.hbase.TestRegionRebalancing
org.apache.hadoop.hbase.master.TestMasterOperationsForRegionReplicas
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/10305//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10305//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10305//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10305//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10305//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10305//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10305//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10305//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10305//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10305//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10305//console
This message is automatically generated.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Attachments: HBASE_11657.patch, HBASE_11657_v2.patch
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14084756#comment-14084756
]
Nick Dimiduk commented on HBASE-11657:
--
For another straw man, how about extracting these from HTable and non-DDL
methods from Admin, making a location services class? Call it {{MetaClient}} or
{{LocationServices}} or something.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14084768#comment-14084768
]
Lars Hofhansl commented on HBASE-11657:
---
We had discussed adding these to HTableInterface before and decided that the
region methods would leak implementation detailse. As such they do not really
belong into the interface. But if we need them there, we can add them, IMHO.
I do like the {{LocationService}} idea.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14084909#comment-14084909
]
Andrew Purtell commented on HBASE-11657:
{{LocationServices}} sounds good, so did the OP's proposed name of
{{HRegionInterface}}, but the direction of new APIs in a few issues is to drop
the 'H', so the former is better I think.
Are we going to locate more than regions with this API? Such as master service
endpoints? REST gateways? Thrift gateways?
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14084920#comment-14084920
]
Mikhail Antonov commented on HBASE-11657:
-
As yet another straw man..methods like getRegionLocation() are also in
HConneciton interface, but marked as deprecated. Shall they be removed from
there too?
Also just my 2 cents.. Like the idea of separate class focused on region
lookups. As I think about inheritance though, making HTable implement HRegion
seems a little bit strange to me?
LocationService name sound a bit too generic to me, or would it be meant for
all sorts of lookups (meta location, master location, regions location etc?)
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14084929#comment-14084929
]
stack commented on HBASE-11657:
---
Suggest keeping narrow scope for this new Interface addition so RegionLocation?
LocationServices sounds like a good idea especially as [~apurtell] would have
it as general lookup entry point. 'H' prefix is from another era -- we don't
do that anymore -- and the Interface suffix gets added when we are in a naming
hole with no other way out (Wondering why we didn't call HTableInterface
Table?).
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14084937#comment-14084937
]
Carter commented on HBASE-11657:
Okay, these are the region-related methods I spot in Admin. I think these
should move to the third, new interface:
{code}
void closeRegion(final byte[] regionname, final String serverName)
boolean closeRegionWithEncodedRegionName(final String encodedRegionName, final
String serverName)
void closeRegion(final ServerName sn, final HRegionInfo hri)
ListHRegionInfo getOnlineRegions(final ServerName sn)
void move(final byte[] encodedRegionName, final byte[] destServerName)
void assign(final byte[] regionName)
void unassign(final byte[] regionName, final boolean force)
void offline(final byte[] regionName)
boolean setBalancerRunning(final boolean on, final boolean synchronous)
boolean balancer()
void mergeRegions(final byte[] encodedNameOfRegionA, final byte[]
encodedNameOfRegionB, final boolean forcible)
void stopRegionServer(final String hostnamePort)
ListHRegionInfo getTableRegions(final TableName tableName)
byte[][] rollHLogWriter(String serverName)
{code}
Then there are a bunch of methods that take _tableNameOrRegionName_ as a
parameter: (Suggestions?)
{code}
flush
compact
majorCompact
split
getCompactionState
{code}
There are also a handful of DDL methods that also do region-y things. For
example:
{code}
void createTable(HTableDescriptor desc, byte[] startKey, byte[] endKey, int
numRegions)
void createTable(final HTableDescriptor desc, byte[][] splitKeys)
{code}
And there are a handful of operational methods, which seem like they should be
in Admin, but are not DDL-related. I think these should stay in Admin:
{code}
ClusterStatus getClusterStatus()
void stopMaster()
void shutdown()
String[] getMasterCoprocessors()
CoprocessorRpcChannel coprocessorService()
void execProcedure(String signature, String instance, MapString, String props)
all the snapshot methods
the catalog janitor methods
{code}
Thoughts on the revised strawman?
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14085094#comment-14085094
]
stack commented on HBASE-11657:
---
[~carterpage] Now you would expand scope of the new Interface to include all
Region operations? Not just obtaining region location? Thats a bigger change.
Do you need that in hbase 1.0 API? Such a fat Interface we'd call Region?
We'd not want HTable implementing this fatter Interface that does admin ops too
right? This fat Region Interface could implement the narrower RegionLocation
Interface?
On the ops that take a region name or a table name, we'd like to fix it so its
explicit which you are doing rather than have the one method do both operations.
createTable* seems at home in the Admin Interface (IMO) Ditto on shutdown,
snapshot, etc.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14085111#comment-14085111
]
Carter commented on HBASE-11657:
How about I start with the first change -- moving region stuff out of HTable
into a new interface called RegionLocation (or just Region?).
Once that's done, I open a new JIRA where I move over the obvious region stuff
from Admin. Then another one to split the _tableNameOrRegionName_ methods into
multiple strongly-typed methods.
Does that work for everyone? Thoughts on _RegionLocation_ vs _Region_?
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14085127#comment-14085127
]
stack commented on HBASE-11657:
---
+1 on RegionLocation. A fat Region Interface could implement this
RegionLocation. HTableInterface can cleanly implement RegionLocation w/o
pulling in other baggage.
bq. Once that's done, I open a new JIRA where I move over the obvious region
stuff from Admin.
+1 on new Issue for this discussion. Need to be careful disrupting API this
close to 1.0.
bq. Then another one to split the tableNameOrRegionName methods into multiple
strongly-typed methods.
This would work. Might be case of deprecating the old in favor of the new
methods. The old would be retained in hbase 1.0 so folks rolling up from 0.98
or earlier aren't broke.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14085139#comment-14085139
]
Mikhail Antonov commented on HBASE-11657:
-
[~carterpage] I think RegionLocation is good if it'd be only limited to lookup
methods currently sitting in HTable, no flush, compact etc?
Also on above, methods like stopRegionServer() aren't related to regions
themselves, are they?
Another thought I have in mind - let's make it specific whether this interface
would be used equally on client side and inside the server (as I'm now working
on abstracting client from ZK, I''m trying to define more precisely where the
code is meant to run).
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14085189#comment-14085189
]
Carter commented on HBASE-11657:
Two more questions before I start:
# There is an existing RegionLocations class in the client. We're okay with
any potential confusion of RegionLocations vs RegionLocation?
# Do we want to deprecate #getRegionLocation(String) and point users to
getRegionLocation(byte[])?
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
[
https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14085302#comment-14085302
]
Mikhail Antonov commented on HBASE-11657:
-
Maybe name it RegionLocator or RegionLocationHelper in this case?
RegionLocation indeed sound more like a holder for individual region location
info.
Put HTable region methods in an interface
-
Key: HBASE-11657
URL: https://issues.apache.org/jira/browse/HBASE-11657
Project: HBase
Issue Type: Improvement
Affects Versions: 0.99.0
Reporter: Carter
Assignee: Carter
Fix For: 0.99.0
Most of the HTable methods are now abstracted by HTableInterface, with the
notable exception of the following methods that pertain to region metadata:
{code}
HRegionLocation getRegionLocation(final String row)
HRegionLocation getRegionLocation(final byte [] row)
HRegionLocation getRegionLocation(final byte [] row, boolean reload)
byte [][] getStartKeys()
byte[][] getEndKeys()
Pairbyte[][],byte[][] getStartEndKeys()
void clearRegionCache()
{code}
and a default scope method which maybe should be bundled with the others:
{code}
ListRegionLocations listRegionLocations()
{code}
Since the consensus seems to be that these would muddy HTableInterface with
non-core functionality, where should it go? MapReduce looks up the region
boundaries, so it needs to be exposed somewhere.
Let me throw out a straw man to start the conversation. I propose:
{code}
org.apache.hadoop.hbase.client.HRegionInterface
{code}
Have HTable implement this interface. Also add these methods to HConnection:
{code}
HRegionInterface getTableRegion(TableName tableName)
HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
{code}
[~stack], [~ndimiduk], [~enis], thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
