[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15088860#comment-15088860 ] Hudson commented on HBASE-14227: FAILURE: Integrated in HBase-1.1-JDK7 #1635 (See [https://builds.apache.org/job/HBase-1.1-JDK7/1635/]) HBASE-14227 Reduce the number of time row comparison is done in a Scan (ramkrishna: rev d2d3c149e6165b1308e565f3ee3136b10ac95b0b) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15088995#comment-15088995 ] Hudson commented on HBASE-14227: SUCCESS: Integrated in HBase-1.2 #494 (See [https://builds.apache.org/job/HBase-1.2/494/]) HBASE-14227 Reduce the number of time row comparison is done in a Scan (ramkrishna: rev abcab52695e7737d78fe5285e22e2fe5caf78421) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089015#comment-15089015 ] Hudson commented on HBASE-14227: SUCCESS: Integrated in HBase-1.3 #486 (See [https://builds.apache.org/job/HBase-1.3/486/]) HBASE-14227 Reduce the number of time row comparison is done in a Scan (ramkrishna: rev e32e4df780bf1935d8421d70af2f3d84ae88f590) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089214#comment-15089214 ] Hudson commented on HBASE-14227: FAILURE: Integrated in HBase-1.2 #495 (See [https://builds.apache.org/job/HBase-1.2/495/]) Revert "HBASE-14227 Reduce the number of time row comparison is done in (ramkrishna: rev 44e82645838c3c5529c5c98a25dcaa60cf0e1fe4) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089262#comment-15089262 ] Hudson commented on HBASE-14227: SUCCESS: Integrated in HBase-1.3 #487 (See [https://builds.apache.org/job/HBase-1.3/487/]) Revert "HBASE-14227 Reduce the number of time row comparison is done in (ramkrishna: rev 323d5c97d92fe8bce3c2bf8e38e68e5fef5ceba6) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089088#comment-15089088 ] Hudson commented on HBASE-14227: SUCCESS: Integrated in HBase-1.2-IT #385 (See [https://builds.apache.org/job/HBase-1.2-IT/385/]) Revert "HBASE-14227 Reduce the number of time row comparison is done in (ramkrishna: rev 44e82645838c3c5529c5c98a25dcaa60cf0e1fe4) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089294#comment-15089294 ] Hudson commented on HBASE-14227: SUCCESS: Integrated in HBase-1.3-IT #429 (See [https://builds.apache.org/job/HBase-1.3-IT/429/]) Revert "HBASE-14227 Reduce the number of time row comparison is done in (ramkrishna: rev 323d5c97d92fe8bce3c2bf8e38e68e5fef5ceba6) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089363#comment-15089363 ] Hudson commented on HBASE-14227: FAILURE: Integrated in HBase-1.1-JDK8 #1723 (See [https://builds.apache.org/job/HBase-1.1-JDK8/1723/]) Revert "HBASE-14227 Reduce the number of time row comparison is done in (ramkrishna: rev fd3d4e3d6e940851f553aeab40ca3a202cdb99ff) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089372#comment-15089372 ] Hudson commented on HBASE-14227: FAILURE: Integrated in HBase-1.1-JDK7 #1636 (See [https://builds.apache.org/job/HBase-1.1-JDK7/1636/]) Revert "HBASE-14227 Reduce the number of time row comparison is done in (ramkrishna: rev fd3d4e3d6e940851f553aeab40ca3a202cdb99ff) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15089548#comment-15089548 ] Hudson commented on HBASE-14227: FAILURE: Integrated in HBase-1.0 #1132 (See [https://builds.apache.org/job/HBase-1.0/1132/]) HBASE-14227 Reduce the number of time row comparison is done in a Scan (ramkrishna: rev 13bbd722650affcea9e9f876c078c0da7a3aba99) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java Revert "HBASE-14227 Reduce the number of time row comparison is done in (ramkrishna: rev 5d854d3802cd1bcf50fea3c2a187d75d51567308) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15088796#comment-15088796 ] Hudson commented on HBASE-14227: SUCCESS: Integrated in HBase-1.3-IT #427 (See [https://builds.apache.org/job/HBase-1.3-IT/427/]) HBASE-14227 Reduce the number of time row comparison is done in a Scan (ramkrishna: rev e32e4df780bf1935d8421d70af2f3d84ae88f590) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15088844#comment-15088844 ] Hudson commented on HBASE-14227: SUCCESS: Integrated in HBase-1.2-IT #384 (See [https://builds.apache.org/job/HBase-1.2-IT/384/]) HBASE-14227 Reduce the number of time row comparison is done in a Scan (ramkrishna: rev abcab52695e7737d78fe5285e22e2fe5caf78421) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15088837#comment-15088837 ] Hudson commented on HBASE-14227: FAILURE: Integrated in HBase-1.1-JDK8 #1722 (See [https://builds.apache.org/job/HBase-1.1-JDK8/1722/]) HBASE-14227 Reduce the number of time row comparison is done in a Scan (ramkrishna: rev d2d3c149e6165b1308e565f3ee3136b10ac95b0b) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934374#comment-14934374 ] Hudson commented on HBASE-14227: FAILURE: Integrated in HBase-TRUNK #6848 (See [https://builds.apache.org/job/HBase-TRUNK/6848/]) HBASE-14500 Remove load of deprecated MOB ruby scripts after HBASE-14227 (esteban: rev 54b86b33940b57140d665a02156cfcf14ba792a2) * hbase-shell/src/main/ruby/shell.rb > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909131#comment-14909131 ] Hudson commented on HBASE-14227: FAILURE: Integrated in HBase-TRUNK #6845 (See [https://builds.apache.org/job/HBase-TRUNK/6845/]) HBASE-14227 Fold special cased MOB APIs into existing APIs (apurtell: rev 02699fe967dde00cde3fc96af782401440dfe2ac) * hbase-shell/src/main/ruby/shell/commands/major_compact.rb * hbase-client/src/main/java/org/apache/hadoop/hbase/client/Admin.java * hbase-it/src/test/java/org/apache/hadoop/hbase/chaos/actions/CompactMobAction.java * hbase-shell/src/main/ruby/shell/commands/major_compact_mob.rb * hbase-server/src/test/java/org/apache/hadoop/hbase/mob/compactions/TestMobCompactor.java * hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java * hbase-shell/src/main/ruby/shell/commands/compact_mob.rb * hbase-shell/src/main/ruby/shell/commands/compact.rb * hbase-shell/src/main/ruby/hbase/admin.rb > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14908968#comment-14908968 ] Andrew Purtell commented on HBASE-14227: I see your new TODO in the patch [~chenheng]. Looks ok for now, I will commit this shortly. Thanks for hanging in there. > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907757#comment-14907757
]
Hadoop QA commented on HBASE-14227:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12762316/HBASE-14227_v6.patch
against master branch at commit 23506454cf92d532630b7442bd570ae0b5dd0a52.
ATTACHMENT ID: 12762316
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 7 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0 2.7.1)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1785 checkstyle errors (more than the master's current 1783 errors).
{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 post-site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
at
org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileScanning(TestHRegion.java:3890)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/15735//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/15735//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/15735//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/15735//console
This message is automatically generated.
> Fold special cased MOB APIs into existing APIs
> --
>
> Key: HBASE-14227
> URL: https://issues.apache.org/jira/browse/HBASE-14227
> Project: HBase
> Issue Type: Task
> Components: mob
>Affects Versions: 2.0.0
>Reporter: Andrew Purtell
>Assignee: Heng Chen
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-14227.patch, HBASE-14227_v1.patch,
> HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch,
> HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch,
> HBASE-14227_v7.patch
>
>
> There are a number of APIs that came in with MOB that are not new actions for
> HBase, simply new actions for a MOB implementation:
> - compactMob
> - compactMobs
> - majorCompactMob
> - majorCompactMobs
> - getMobCompactionState
> And in HBaseAdmin:
> - validateMobColumnFamily
> Remove these special cases from the Admin API where possible by folding them
> into existing APIs.
> We definitely don't need one method for a singleton and another for
> collections.
> Ideally we will not have any APIs named *Mob when finished, whether MOBs are
> in use on a table or not should be largely an internal detail. Exposing as
> schema option would be fine, this conforms to existing practice for other
> features.
> Marking critical because I think removing the *Mob special cased APIs should
> be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907799#comment-14907799
]
Hadoop QA commented on HBASE-14227:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12762317/HBASE-14227_v7.patch
against master branch at commit a33adf2f0b050e9cf9330fd5ab7e200a7dd27d6d.
ATTACHMENT ID: 12762317
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 7 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0 2.7.1)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1785 checkstyle errors (more than the master's current 1783 errors).
{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 post-site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.master.procedure.TestWALProcedureStoreOnHDFS
{color:red}-1 core zombie tests{color}. There are 4 zombie test(s):
at
org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScanBase.testScan(TestTableInputFormatScanBase.java:243)
at
org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan1.testScanEmptyToAPP(TestTableInputFormatScan1.java:58)
at
org.apache.hadoop.hbase.mapreduce.TableSnapshotInputFormatTestBase.testWithMapReduce(TableSnapshotInputFormatTestBase.java:164)
at
org.apache.hadoop.hbase.mapreduce.TableSnapshotInputFormatTestBase.testWithMapReduceMultiRegion(TableSnapshotInputFormatTestBase.java:101)
at
org.apache.hadoop.hbase.mapreduce.TestCellCounter.testCellCounter(TestCellCounter.java:99)
at
org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat.testMRIncrementalLoadWithSplit(TestHFileOutputFormat.java:384)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/15736//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/15736//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/15736//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/15736//console
This message is automatically generated.
> Fold special cased MOB APIs into existing APIs
> --
>
> Key: HBASE-14227
> URL: https://issues.apache.org/jira/browse/HBASE-14227
> Project: HBase
> Issue Type: Task
> Components: mob
>Affects Versions: 2.0.0
>Reporter: Andrew Purtell
>Assignee: Heng Chen
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-14227.patch, HBASE-14227_v1.patch,
> HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch,
> HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch,
> HBASE-14227_v7.patch
>
>
> There are a number of APIs that came in with MOB that are not new actions for
> HBase, simply new actions for a MOB implementation:
> - compactMob
> - compactMobs
> - majorCompactMob
> - majorCompactMobs
> - getMobCompactionState
> And in HBaseAdmin:
> - validateMobColumnFamily
> Remove these special cases from the Admin API where possible by folding them
> into existing APIs.
> We definitely don't need one method for a singleton and another for
> collections.
> Ideally we will not have any APIs named *Mob when finished, whether MOBs are
> in use on a table or not should be largely an internal detail. Exposing as
> schema option would be fine, this conforms to existing practice for other
> features.
> Marking critical because I think removing the *Mob special cased APIs should
> be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907868#comment-14907868 ] Heng Chen commented on HBASE-14227: --- TestWALProcedureStoreOnHDFS failed will be fixed in HBASE-14362 It has no relates with this patch > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch, HBASE-14227_v6.patch, > HBASE-14227_v7.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14906145#comment-14906145 ] Heng Chen commented on HBASE-14227: --- Anybody who can help me review this? > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907391#comment-14907391 ] Andrew Purtell commented on HBASE-14227: We can still commit this change that updates the user facing API first, then apply your changes to use execProcedure behind the scenes after, right [~jingchengdu]? > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907430#comment-14907430
]
Heng Chen commented on HBASE-14227:
---
{quote}
So after the procedure patch is applied, should we remains the APIs brought in
this patch? Please advise. Thanks!
{quote}
I think we should finish this issue first, and after the procedure patch
applied, we can use another issue to discuss whether we should remain the APIs.
> Fold special cased MOB APIs into existing APIs
> --
>
> Key: HBASE-14227
> URL: https://issues.apache.org/jira/browse/HBASE-14227
> Project: HBase
> Issue Type: Task
> Components: mob
>Affects Versions: 2.0.0
>Reporter: Andrew Purtell
>Assignee: Heng Chen
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-14227.patch, HBASE-14227_v1.patch,
> HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch,
> HBASE-14227_v5.patch, HBASE-14227_v5.patch
>
>
> There are a number of APIs that came in with MOB that are not new actions for
> HBase, simply new actions for a MOB implementation:
> - compactMob
> - compactMobs
> - majorCompactMob
> - majorCompactMobs
> - getMobCompactionState
> And in HBaseAdmin:
> - validateMobColumnFamily
> Remove these special cases from the Admin API where possible by folding them
> into existing APIs.
> We definitely don't need one method for a singleton and another for
> collections.
> Ideally we will not have any APIs named *Mob when finished, whether MOBs are
> in use on a table or not should be largely an internal detail. Exposing as
> schema option would be fine, this conforms to existing practice for other
> features.
> Marking critical because I think removing the *Mob special cased APIs should
> be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907447#comment-14907447 ] Jingcheng Du commented on HBASE-14227: -- Thanks guys for comments. bq. I think we should finish this issue first, and after the procedure patch applied, we can use another issue to discuss whether we should remain the APIs Right, please go ahead:) > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907366#comment-14907366 ] Jingcheng Du commented on HBASE-14227: -- Sorry for the late response. I'm ok with the current patch. I am currently work on implementing mob compaction with procedure. After that we can use Admin.execProcedure to invoke the mob compaction instead of the current APIs (compactMob, majorCompactMob, etc.). So what do you guys think of this? Which way should we choose? # Apply the code of current patch. # Use Admin.execProcedure after the procedure mob compaction is finished. Please advise. Thanks a lot! > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907316#comment-14907316 ] Andrew Purtell commented on HBASE-14227: Sorry this has been neglected [~chenheng]. Mostly lgtm. In HBaseAdmin the patch calls getClusterStatus in a few places only to get the ServerName of the master. getClusterStatus is really expensive, and this ultimately contacts the master to find the master's address. Consider MasterAddressTracker#getMasterAddress(ZooKeeperWatcher) instead. Can we also change the shell to remove thel *_mob commands there? Expose the CompactType types as constants on the ruby side and change the current compact and major_compact command to accept an optional additional parameter which specifies the compaction type, defaulting to 'NORMAL'. > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907425#comment-14907425
]
Andrew Purtell commented on HBASE-14227:
What I want to see happen is in the original description of this issue:
{quote}
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
{quote}
The current patch achieves this aim. I think it is mostly ready to go but have
some comments above that could be addressed, especially the use of
getClusterStatus (please fix that)
If your patch also achieves the described aim [~jingcheng...@intel.com], then I
would be happy either way and you and [~chenheng] can decide what you'd prefer.
> Fold special cased MOB APIs into existing APIs
> --
>
> Key: HBASE-14227
> URL: https://issues.apache.org/jira/browse/HBASE-14227
> Project: HBase
> Issue Type: Task
> Components: mob
>Affects Versions: 2.0.0
>Reporter: Andrew Purtell
>Assignee: Heng Chen
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-14227.patch, HBASE-14227_v1.patch,
> HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch,
> HBASE-14227_v5.patch, HBASE-14227_v5.patch
>
>
> There are a number of APIs that came in with MOB that are not new actions for
> HBase, simply new actions for a MOB implementation:
> - compactMob
> - compactMobs
> - majorCompactMob
> - majorCompactMobs
> - getMobCompactionState
> And in HBaseAdmin:
> - validateMobColumnFamily
> Remove these special cases from the Admin API where possible by folding them
> into existing APIs.
> We definitely don't need one method for a singleton and another for
> collections.
> Ideally we will not have any APIs named *Mob when finished, whether MOBs are
> in use on a table or not should be largely an internal detail. Exposing as
> schema option would be fine, this conforms to existing practice for other
> features.
> Marking critical because I think removing the *Mob special cased APIs should
> be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14907399#comment-14907399 ] Jingcheng Du commented on HBASE-14227: -- Yes, we can! So after the procedure patch is applied, should we remains the APIs brought in this patch? Please advise. Thanks! > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14738335#comment-14738335 ] Heng Chen commented on HBASE-14227: --- Any suggestions? [~anoop.hbase] [~jingcheng...@intel.com] > Fold special cased MOB APIs into existing APIs > -- > > Key: HBASE-14227 > URL: https://issues.apache.org/jira/browse/HBASE-14227 > Project: HBase > Issue Type: Task > Components: mob >Affects Versions: 2.0.0 >Reporter: Andrew Purtell >Assignee: Heng Chen >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, > HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, > HBASE-14227_v5.patch, HBASE-14227_v5.patch > > > There are a number of APIs that came in with MOB that are not new actions for > HBase, simply new actions for a MOB implementation: > - compactMob > - compactMobs > - majorCompactMob > - majorCompactMobs > - getMobCompactionState > And in HBaseAdmin: > - validateMobColumnFamily > Remove these special cases from the Admin API where possible by folding them > into existing APIs. > We definitely don't need one method for a singleton and another for > collections. > Ideally we will not have any APIs named *Mob when finished, whether MOBs are > in use on a table or not should be largely an internal detail. Exposing as > schema option would be fine, this conforms to existing practice for other > features. > Marking critical because I think removing the *Mob special cased APIs should > be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14724490#comment-14724490
]
Hadoop QA commented on HBASE-14227:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12753380/HBASE-14227_v5.patch
against master branch at commit 498c1845ab7b01710955153c27501fdc7492849d.
ATTACHMENT ID: 12753380
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 7 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0 2.7.1)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1848 checkstyle errors (more than the master's current 1846 errors).
{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 post-site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/15362//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/15362//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/15362//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/15362//console
This message is automatically generated.
> Fold special cased MOB APIs into existing APIs
> --
>
> Key: HBASE-14227
> URL: https://issues.apache.org/jira/browse/HBASE-14227
> Project: HBase
> Issue Type: Task
> Components: mob
>Affects Versions: 2.0.0
>Reporter: Andrew Purtell
>Assignee: Heng Chen
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-14227.patch, HBASE-14227_v1.patch,
> HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch,
> HBASE-14227_v5.patch, HBASE-14227_v5.patch
>
>
> There are a number of APIs that came in with MOB that are not new actions for
> HBase, simply new actions for a MOB implementation:
> - compactMob
> - compactMobs
> - majorCompactMob
> - majorCompactMobs
> - getMobCompactionState
> And in HBaseAdmin:
> - validateMobColumnFamily
> Remove these special cases from the Admin API where possible by folding them
> into existing APIs.
> We definitely don't need one method for a singleton and another for
> collections.
> Ideally we will not have any APIs named *Mob when finished, whether MOBs are
> in use on a table or not should be largely an internal detail. Exposing as
> schema option would be fine, this conforms to existing practice for other
> features.
> Marking critical because I think removing the *Mob special cased APIs should
> be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14721933#comment-14721933
]
Hadoop QA commented on HBASE-14227:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12753222/HBASE-14227_v5.patch
against master branch at commit df341c4299ea21e4e1ca09652f6126633f2307c5.
ATTACHMENT ID: 12753222
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 7 new
or modified tests.
{color:red}-1 javac{color}. The patch appears to cause mvn compile goal to
fail with Hadoop version 2.4.0.
Compilation errors resume:
[ERROR] Error invoking method 'get(java.lang.Integer)' in
java.util.ArrayList at META-INF/LICENSE.vm[line 1619, column 22]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process (default) on
project hbase-assembly: Error rendering velocity resource. Error invoking
method 'get(java.lang.Integer)' in java.util.ArrayList at
META-INF/LICENSE.vm[line 1619, column 22]: InvocationTargetException: Index: 0,
Size: 0 - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn goals -rf :hbase-assembly
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/15331//console
This message is automatically generated.
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Assignee: Heng Chen
Priority: Blocker
Fix For: 2.0.0
Attachments: HBASE-14227.patch, HBASE-14227_v1.patch,
HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch,
HBASE-14227_v5.patch
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14718126#comment-14718126
]
Hadoop QA commented on HBASE-14227:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12752927/HBASE-14227_v5.patch
against master branch at commit cc1542828de93b8d54cc14497fd5937989ea1b6d.
ATTACHMENT ID: 12752927
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 7 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0 2.7.1)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1851 checkstyle errors (more than the master's current 1849 errors).
{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 post-site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.TestIOFencing
{color:red}-1 core zombie tests{color}. There are 7 zombie test(s):
at
org.apache.hadoop.hbase.security.access.TestAccessController.testAccessControllerUserPermsRegexHandling(TestAccessController.java:2560)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/15313//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/15313//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/15313//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/15313//console
This message is automatically generated.
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Assignee: Heng Chen
Priority: Blocker
Fix For: 2.0.0
Attachments: HBASE-14227.patch, HBASE-14227_v1.patch,
HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch,
HBASE-14227_v5.patch
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14716160#comment-14716160
]
Jingcheng Du commented on HBASE-14227:
--
-1 lineLengths. The patch introduces the following lines longer than 100:
+ public void compact(final TableName tableName, CompactType compactType)
throws IOException, InterruptedException {
+ public void majorCompact(final TableName tableName, final byte[]
columnFamily, CompactType compactType)
+ public CompactionState getCompactionState(TableName tableName, CompactType
compactType) throws IOException {
+ @admin.majorCompact(org.apache.hadoop.hbase.TableName.valueOf(table_name),
family.to_java_bytes,
Please trim these lines, and make sure they are not longer than 100. Thanks!
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Assignee: Heng Chen
Priority: Blocker
Fix For: 2.0.0
Attachments: HBASE-14227.patch, HBASE-14227_v1.patch,
HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14716151#comment-14716151
]
Hadoop QA commented on HBASE-14227:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12752653/HBASE-14227_v4.patch
against master branch at commit 56890d9fe148dd192520fab349a66aa3f688e232.
ATTACHMENT ID: 12752653
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 7 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1854 checkstyle errors (more than the master's current 1849 errors).
{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:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ public void compact(final TableName tableName, CompactType compactType)
throws IOException, InterruptedException {
+ public void majorCompact(final TableName tableName, final byte[]
columnFamily, CompactType compactType)
+ public CompactionState getCompactionState(TableName tableName, CompactType
compactType) throws IOException {
+
@admin.majorCompact(org.apache.hadoop.hbase.TableName.valueOf(table_name),
family.to_java_bytes,
{color:green}+1 site{color}. The mvn post-site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.TestStochasticBalancerJmxMetrics
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/15285//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/15285//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/15285//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/15285//console
This message is automatically generated.
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Assignee: Heng Chen
Priority: Blocker
Fix For: 2.0.0
Attachments: HBASE-14227.patch, HBASE-14227_v1.patch,
HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14716457#comment-14716457 ] Heng Chen commented on HBASE-14227: --- I think the testcase failed was not caused by this patch. I will retry later. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch, HBASE-14227_v5.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14716333#comment-14716333
]
Hadoop QA commented on HBASE-14227:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12752675/HBASE-14227_v5.patch
against master branch at commit 56890d9fe148dd192520fab349a66aa3f688e232.
ATTACHMENT ID: 12752675
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 7 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1851 checkstyle errors (more than the master's current 1849 errors).
{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 post-site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
{color:red}-1 core zombie tests{color}. There are 9 zombie test(s):
at
org.apache.hadoop.hbase.mapreduce.TestLoadIncrementalHFiles.testSimpleHFileSplit(TestLoadIncrementalHFiles.java:153)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/15289//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/15289//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/15289//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/15289//console
This message is automatically generated.
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Assignee: Heng Chen
Priority: Blocker
Fix For: 2.0.0
Attachments: HBASE-14227.patch, HBASE-14227_v1.patch,
HBASE-14227_v2.patch, HBASE-14227_v3.patch, HBASE-14227_v4.patch,
HBASE-14227_v5.patch
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14716030#comment-14716030
]
Hadoop QA commented on HBASE-14227:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12752639/HBASE-14227_v3.patch
against master branch at commit 56890d9fe148dd192520fab349a66aa3f688e232.
ATTACHMENT ID: 12752639
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 7 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
1854 checkstyle errors (more than the master's current 1849 errors).
{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:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ public void compact(final TableName tableName, CompactType compactType)
throws IOException, InterruptedException {
+ public void majorCompact(final TableName tableName, final byte[]
columnFamily, CompactType compactType)
+ public CompactionState getCompactionState(TableName tableName, CompactType
compactType) throws IOException {
+@admin.compact(org.apache.hadoop.hbase.TableName.valueOf(table_name),
org.apache.hadoop.hbase.client.Admin.CompactType.MOB)
+@admin.compact(org.apache.hadoop.hbase.TableName.valueOf(table_name),
family.to_java_bytes, org.apache.hadoop.hbase.client.Admin.CompactType.MOB)
+
@admin.majorCompact(org.apache.hadoop.hbase.TableName.valueOf(table_name),
org.apache.hadoop.hbase.client.Admin.CompactType.MOB)
+
@admin.majorCompact(org.apache.hadoop.hbase.TableName.valueOf(table_name),
family.to_java_bytes, org.apache.hadoop.hbase.client.Admin.CompactType.MOB)
{color:green}+1 site{color}. The mvn post-site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.TestInterfaceAudienceAnnotations
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
at
org.apache.sentry.tests.e2e.hive.AbstractTestWithStaticConfiguration.clearAll(AbstractTestWithStaticConfiguration.java:475)
at
org.apache.sentry.tests.e2e.hive.AbstractTestWithStaticConfiguration.clearAfterPerTest(AbstractTestWithStaticConfiguration.java:463)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/15282//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/15282//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/15282//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/15282//console
This message is automatically generated.
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Assignee: Heng Chen
Priority: Blocker
Fix For: 2.0.0
Attachments: HBASE-14227.patch, HBASE-14227_v1.patch,
HBASE-14227_v2.patch, HBASE-14227_v3.patch
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712507#comment-14712507 ] Anoop Sam John commented on HBASE-14227: Bit more correction needed in the doc for CompactType which can be corrected on commit. Once QA is ok am +1 Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, HBASE-14227_v2.patch, HBASE-14227_v3.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14706451#comment-14706451
]
Jingcheng Du commented on HBASE-14227:
--
Thanks [~chenheng]!
Maybe too many details for a public client. Sorry for mislead in my previous
comments.
How about this?
{noformat}
/**
* The compaction types.
* {@code NORMAL} is for compaction in store files.
* {@code MOB} is for mob. If it is used the compaction of mob files is
triggered.
**/
{noformat}
[~anoopsamjohn], do you want to have a look and give some advice? Thanks.
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Assignee: Heng Chen
Priority: Blocker
Fix For: 2.0.0
Attachments: HBASE-14227.patch, HBASE-14227_v1.patch,
HBASE-14227_v2.patch, HBASE-14227_v3.patch
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14704391#comment-14704391 ] Jingcheng Du commented on HBASE-14227: -- The comments about the CompactType seems not enough, the words Currently, there are only two compact types: is not a good choice in comments. We need to tell what it is and why we have this, for instance differentiate the compaction between store files and mob files. Do you have suggestion on this? [~anoopsamjohn], thanks. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, HBASE-14227_v2.patch, HBASE-14227_v3.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14706017#comment-14706017
]
Heng Chen commented on HBASE-14227:
---
How about this
{code}
+ /**
+ * {@code NORMAL} means do store files compaction;
+ * {@code MOB} means do mob files compaction.
+ * It is different, MOB compaction only take care of MOB files.
+ * Generally, MOB CF is larger than normal CF, a compaction on the MOB CF
will be more IO oriented than the normal CF.
+ * And the impact of the number of MOB files is not significant in read,
usually they are deleted when expired.
+ * So sometimes MOB compactions are not necessary. More MOB detail see
HBASE-11339
+ * */
+ public enum CompactType {
+
+NORMAL(0),
+MOB (1);
+
+CompactType(int value) {}
+ }
{code}
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Assignee: Heng Chen
Priority: Blocker
Fix For: 2.0.0
Attachments: HBASE-14227.patch, HBASE-14227_v1.patch,
HBASE-14227_v2.patch, HBASE-14227_v3.patch
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14704333#comment-14704333 ] Anoop Sam John commented on HBASE-14227: Looks good overall. We will need a bit of explanation for the new param 'compactType'. And also at the new enum. (javadoc) To tell what will get compacted when Normal and what when MOB. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch, HBASE-14227_v1.patch, HBASE-14227_v2.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702768#comment-14702768 ] Anoop Sam John commented on HBASE-14227: HRegionInfo is public exposed. Can we avoid getMobRegionInfo added there? MobUtil can have this method? Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch, HBASE-14227_v1.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702781#comment-14702781
]
Heng Chen commented on HBASE-14227:
---
{quote}
HRegionInfo is public exposed. Can we avoid getMobRegionInfo added there?
MobUtil can have this method?
{quote}
{{MobUtils}} is in hbase-server module, but {{HbaseAdmin}} is in hbase-client.
If move this method into {{MobUtils}}, the client will depend on server jar,
is it good?
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Assignee: Heng Chen
Priority: Blocker
Fix For: 2.0.0
Attachments: HBASE-14227.patch, HBASE-14227_v1.patch
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702787#comment-14702787 ] Jingcheng Du commented on HBASE-14227: -- Please don't move the MobUtils to client where a lot of hbase-region classes are used. We cannot reference server stuff from client module. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch, HBASE-14227_v1.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14704230#comment-14704230 ] Jingcheng Du commented on HBASE-14227: -- Good one! Thanks. # As [~anoopsamjohn]'s concern, should we remove the getMobRegionInfo out from HReginoInfo, and move it back to HBaseAdmin as a private method? # Remove the un-used private methods used by mob, for instance checkFamilyNameNotNull, validateMobColumnFamily, etc. # Add comments for new parameters and methods. I'll be +1 after the above things are addressed! Thanks! Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch, HBASE-14227_v1.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701043#comment-14701043 ] Jingcheng Du commented on HBASE-14227: -- bq. There is no need to do this. If CF is passed in, we can check schema option to decide whether the CF is MOB or not Compacting the store files with ref cells and mob files are different. But they share the same CF. We want to separate the compactions, and we have to separate these operations in methods. If only with CF, we only know the cf is a mob-enable cf, but we don't know what kind of compaction is needed. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Priority: Blocker Fix For: 2.0.0 There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700941#comment-14700941 ] Anoop Sam John commented on HBASE-14227: This will work for the APIs which takes region name too. WHat abt API which takes only table name? Expectation is compact all regions for it. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Priority: Blocker Fix For: 2.0.0 There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701014#comment-14701014 ] Jingcheng Du commented on HBASE-14227: -- No need for region level, just need to tell table and CF name. The thing is we don't want to do the compaction in store files and mob files together. The ref cells of mob are stored in store file in hbase, and the real mob data are stored in mob files outside hbase directory. The hbase compaction only needs to compact the ref cells, and mob compaction takes care of mob files. The impact of the number of mob files is not significant in read, usually they are deleted when expired. Sometimes the compactions to them are not necessary. We have two approaches for this. # Use a special name format in the cf name, if we want to do the mobCompact, we can pass in a special cf name, for instance cf$MOB. # Add two new APIs with one additional parameter (enum or boolean) to switch the mob compaction and normal compaction. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Priority: Blocker Fix For: 2.0.0 There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700962#comment-14700962 ] Heng Chen commented on HBASE-14227: --- I have a question: Is there any need to add interface compact for MOB at table and region level? If user want to compact MOB CF, just specify it at CF Level. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Priority: Blocker Fix For: 2.0.0 There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701027#comment-14701027
]
Heng Chen commented on HBASE-14227:
---
{quote}
1. Use a special name format in the cf name, if we want to do the mobCompact,
we can pass in a special cf name, for instance cf$MOB.
{quote}
There is no need to do this. If CF is passed in, we can check schema option to
decide whether the CF is MOB or not.
The question is when compact on table or region Level, shall we do MOB
compaction?
If we do, the function {{Admin.compact(final TableName tableName)}} need one
additional parameter to switch the mob compaction and normal compaction as
[~jingcheng...@intel.com] said.
If we don't, there is no need to change {{Admin.compact(final TableName
tableName)}}
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Priority: Blocker
Fix For: 2.0.0
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700779#comment-14700779
]
Heng Chen commented on HBASE-14227:
---
{quote}
So when we call compact whether the compaction has to happen for the ref CF or
MOB CF or both?
{quote}
IMO when call {{Admin.compact(final TableName tableName) throws IOException;}},
the compaction would happen for both MOB CF and Normal CF.
So we can check, if table has MOB CF, it would compact on MOB CF after normal
CF compaction. just like below
{code}
if (isMobFamily(tableName, columnFamily)) {
try {
compactMob(tableName, columnFamily, major);
} catch (InterruptedException e) {
LOG.warn(Compact Mob family is interrupted!, e);
}
} else {
// normal compaction
..
//if not specify column family, and table has mob cf, we should request
compact for it.
if (columnFamily == null isMobTable(tableName)) {
try {
compactMob(tableName, null, false);
} catch (InterruptedException e) {
throw new IOException(e);
}
}
}
{code}
And when we call {{Admin.getCompactionState}}, we also do this check if table
has mob cf.
Any concerns?
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Priority: Blocker
Fix For: 2.0.0
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700939#comment-14700939 ] Jingcheng Du commented on HBASE-14227: -- I mean we'd better not compact the normal and mob cf together. I have a way to fold the compactMob into the existing APIs. As you know, the mob is stored in a dummy mob region (with a constant name). We can use the exiting APIs compactRegion and majorCompactRegion to do this. # If the region name is a mob region name, we do compaction of mob. # Otherwise do normal compaction. How about this? Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Priority: Blocker Fix For: 2.0.0 There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700893#comment-14700893
]
Heng Chen commented on HBASE-14227:
---
I see...So i think if columnFamily is specified in {{Admin.compact}}, we
can do mob compaction if the cf is mob one.
And if columnFamily is not specified, we can add another interface like
{{Admin.compact(final TableName tableName, final boolean isMob)}} just as
[~anoop.hbase] said.
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Priority: Blocker
Fix For: 2.0.0
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700870#comment-14700870 ] Jingcheng Du commented on HBASE-14227: -- Agree with [~anoopsamjohn]. compactMob only compacts the mob files. The store files are NOT included in this operations. We can allow less MOB compaction and even disable it. Compacting the normal CF and MOB CF is not a good idea because of mob's big size. The mob APIs can be removed from Admin, and are folded into existing ones. How about using a special name format, for example columnFamily$MOB? So we can know it is used to trigger a mob compaction on a mob-enabled column family? Thanks. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Priority: Blocker Fix For: 2.0.0 There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700791#comment-14700791 ] Anoop Sam John commented on HBASE-14227: bq.IMO when call Admin.compact(final TableName tableName) throws IOException;, the compaction would happen for both MOB CF and Normal CF. Am not having the same opinion. Mainly major compaction. The non MOB CFs users would see to get major compacted after some time/days. But MOB!! The IO there will be much much more. cc [~jingcheng...@intel.com] Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Priority: Blocker Fix For: 2.0.0 There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700942#comment-14700942 ] Jingcheng Du commented on HBASE-14227: -- Wait... We still need table name and cf name in compactRegion, so this approach doesn't work. Sorry. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Priority: Blocker Fix For: 2.0.0 There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701104#comment-14701104
]
Jingcheng Du commented on HBASE-14227:
--
Go through the code, I think we can fold these mob APIs into {{void
compactRegion(final byte[] regionName, final byte[] columnFamily)}} and {{void
majorCompactRegion(final byte[] regionName, final byte[] columnFamily)}}.
# We could know whether it's a mob region by region name.
# Issue the compaction from admin by passing region name and column
name(optional).
I think this can work.
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Priority: Blocker
Fix For: 2.0.0
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702325#comment-14702325 ] Jingcheng Du commented on HBASE-14227: -- Please go ahead for a new patch if you want. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702326#comment-14702326 ] Jingcheng Du commented on HBASE-14227: -- Please go ahead for a new patch if you want. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702328#comment-14702328 ] Jingcheng Du commented on HBASE-14227: -- Guys, do you want to take a look at the first patch and have comments? Thanks. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702327#comment-14702327 ] Jingcheng Du commented on HBASE-14227: -- Please go ahead for a new patch if you want. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702353#comment-14702353
]
Heng Chen commented on HBASE-14227:
---
As your patch, IMO there is one problem. If user want to compact MOB CF, it
needs to call something like {{Admin.compactRegion(mobRegionName)}}.
It means the user has to know what mobRegionName it is. I think this is your
implementation detail, the user has no need to know.
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Assignee: Heng Chen
Priority: Blocker
Fix For: 2.0.0
Attachments: HBASE-14227.patch
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702356#comment-14702356 ] Jingcheng Du commented on HBASE-14227: -- Agree. But there are reasons that compactRegion in Admin exists. It allows users to compact specific regions. In design document, it was mentioned the mob was considered as a dummy region. I think it is ok (?) for users to know this. In order to ease the invocation of compactRegion API, I added a static method to HRegionInfo to create region name by table name. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701052#comment-14701052
]
Heng Chen commented on HBASE-14227:
---
{quote}
Compacting the store files with ref cells and mob files are different. But they
share the same CF. We want to separate the compactions, and we have to separate
these operations in methods. If only with CF, we only know the cf is a
mob-enable cf, but we don't know what kind of compaction is needed.
{quote}
I see... I agree with you. we can use special name to notify us do MOB
compaction.
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Priority: Blocker
Fix For: 2.0.0
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701054#comment-14701054 ] Jingcheng Du commented on HBASE-14227: -- Thanks [~chenheng]! Let's see if any more comments on the first approach (special name format which adds limit to the cf name in that method). Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Priority: Blocker Fix For: 2.0.0 There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702182#comment-14702182
]
Heng Chen commented on HBASE-14227:
---
{quote}
Rather than a boolean I'd suggest a set of flags... I guess the Java idiom is a
List of Enum... for selecting what types of CFs to include in the compaction.
{quote}
I agree with this approach. We remove any mob method. And use one {{Enum}}
parameter to select compaction types.
By the way, i found the issue was assigned to me, but
[~jingcheng...@intel.com] has uploaded the patch.
Do i need to submit patch？ [~apurtell]
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Assignee: Heng Chen
Priority: Blocker
Fix For: 2.0.0
Attachments: HBASE-14227.patch
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14702535#comment-14702535 ] Jingcheng Du commented on HBASE-14227: -- Hi [~chenheng], you can go ahead with a new patch in the enum approach. Thanks. The enum might contains three elements, all, normal, and mob? Not good at naming things. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701284#comment-14701284 ] Dave Latham commented on HBASE-14227: - I'm not a fan of passing behavior arguments as special in band names for something like a column family. It leads to worse documentation, user surprises, and potentially even conflicts if someone already has such a column family. Since MOB compaction actually is a separate thing, it should be reflected in the API by either another parameter or new API methods (though they should be minimized). But just my two cents from an interested user. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Priority: Blocker Fix For: 2.0.0 There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701534#comment-14701534 ] Andrew Purtell commented on HBASE-14227: Agreed overloading existing admin methods with a new option with an additional parameter is a better compromise. What we are doing here is exposing more control over compaction IO scheduling. We should update the APIs with that in mind and not make it MOB specific. Rather than a boolean I'd suggest a set of flags... I guess the Java idiom is a List of Enum... for selecting what types of CFs to include in the compaction. Or, something more flexible (but crazier) like a Filter or Comparator. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701536#comment-14701536 ] Andrew Purtell commented on HBASE-14227: My bad Jingcheng. It should be assigned to whomever is doing the work. Feel free to change. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701535#comment-14701535
]
Jingcheng Du commented on HBASE-14227:
--
Understand your concerns.
So how about passing the mob region name to the existing Admin APIs for
compaction? The mob region name can be found by calling
{{HRegionInfo.getMobRegionName(TableName)}}.
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Assignee: Heng Chen
Priority: Blocker
Fix For: 2.0.0
Attachments: HBASE-14227.patch
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701541#comment-14701541 ] Andrew Purtell commented on HBASE-14227: I really don't like any *mob* API name of any kind. We can leak if a CF is a MOB through schema attributes, that seems fine. Otherwise I feel it is a layering violation. Our APIs shouldn't care what kind of CF is a CF at the level of method names. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701575#comment-14701575 ] Jingcheng Du commented on HBASE-14227: -- Thanks Andy for comments! How about folding the mob compaction into compactRegion/majorCompactRegion? This doesn't add additional words into names of methods. But users need to pass the mob region name (a dummy one) into these methods. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701533#comment-14701533 ] Jingcheng Du commented on HBASE-14227: -- Oops, got race condition with the assign. Sorry for that. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Heng Chen Priority: Blocker Fix For: 2.0.0 Attachments: HBASE-14227.patch There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[
https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14699330#comment-14699330
]
Heng Chen commented on HBASE-14227:
---
Just remove api with mob in {{Admin}}, and add one condition to check whether
the CF mob is enable. It seems not diffculty. Just like below, Am i right?
{code}
private void compact(final TableName tableName, final byte[]
columnFamily,final boolean major)
throws IOException {
if (isMobFamily(tableName, columnFamily)) {
try {
compactMob(tableName, columnFamily, major);
} catch (InterruptedException e) {
LOG.warn(Compact Mob family is interrupted!, e);
}
} else {
ZooKeeperWatcher zookeeper = null;
try {
checkTableExists(tableName);
zookeeper = new ZooKeeperWatcher(conf, ZK_IDENTIFIER_PREFIX +
connection.toString(),
new ThrowableAbortable());
...
}
{code}
Fold special cased MOB APIs into existing APIs
--
Key: HBASE-14227
URL: https://issues.apache.org/jira/browse/HBASE-14227
Project: HBase
Issue Type: Task
Components: mob
Affects Versions: 2.0.0
Reporter: Andrew Purtell
Priority: Blocker
Fix For: 2.0.0
There are a number of APIs that came in with MOB that are not new actions for
HBase, simply new actions for a MOB implementation:
- compactMob
- compactMobs
- majorCompactMob
- majorCompactMobs
- getMobCompactionState
And in HBaseAdmin:
- validateMobColumnFamily
Remove these special cases from the Admin API where possible by folding them
into existing APIs.
We definitely don't need one method for a singleton and another for
collections.
Ideally we will not have any APIs named *Mob when finished, whether MOBs are
in use on a table or not should be largely an internal detail. Exposing as
schema option would be fine, this conforms to existing practice for other
features.
Marking critical because I think removing the *Mob special cased APIs should
be a precondition for release of this feature either in 2.0 or as a backport.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700432#comment-14700432 ] Heng Chen commented on HBASE-14227: --- Can i upload patch for this issue? [~apurtell] Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Priority: Blocker Fix For: 2.0.0 There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700764#comment-14700764 ] Anoop Sam John commented on HBASE-14227: It is not that straight forward change. When we call compact table cf there is a column family for the (normal HBase cf) reference cells which refers to MOB cells. And there is another MOB CF. A compaction on the MOB CF will be more IO oriented than the normal CFs. So when we call compact whether the compaction has to happen for the ref CF or MOB CF or both? May be instead of new APIs as above, it would have been like overloaded APIs with a boolean param which says whether to compact/major compact the MOB CF also? Then there is no need for new CP hooks and the security checks also can be enforced. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Priority: Blocker Fix For: 2.0.0 There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700019#comment-14700019 ] Andrew Purtell commented on HBASE-14227: Yes [~chenheng], something very much like that Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Priority: Blocker Fix For: 2.0.0 There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14227) Fold special cased MOB APIs into existing APIs
[ https://issues.apache.org/jira/browse/HBASE-14227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14698364#comment-14698364 ] Andrew Purtell commented on HBASE-14227: Another strong reason for doing this work is there is no coprocessor API nor AccessController support for securing the MOB admin APIs. Adding APIs specific to MOB could be reasonable at the coprocessor level, I think we'd want to look at that on a case by case basis, and again avoid wherever possible. Fold special cased MOB APIs into existing APIs -- Key: HBASE-14227 URL: https://issues.apache.org/jira/browse/HBASE-14227 Project: HBase Issue Type: Task Components: mob Affects Versions: 2.0.0 Reporter: Andrew Purtell Priority: Critical Fix For: 2.0.0 There are a number of APIs that came in with MOB that are not new actions for HBase, simply new actions for a MOB implementation: - compactMob - compactMobs - majorCompactMob - majorCompactMobs - getMobCompactionState And in HBaseAdmin: - validateMobColumnFamily Remove these special cases from the Admin API where possible by folding them into existing APIs. We definitely don't need one method for a singleton and another for collections. Ideally we will not have any APIs named *Mob when finished, whether MOBs are in use on a table or not should be largely an internal detail. Exposing as schema option would be fine, this conforms to existing practice for other features. Marking critical because I think removing the *Mob special cased APIs should be a precondition for release of this feature either in 2.0 or as a backport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
