[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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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[]) -> list. 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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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 Atlassia
[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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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 getTabl
[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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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 List 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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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],
[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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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) List 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) List 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, Map 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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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-tabpanel&focusedCommentId=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() > Pair getStartEndKeys() > void clearRegionCache() > {code} > and a default scope method which maybe should be bundled with the others: > {code} > List 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)