[jira] [Commented] (HBASE-19043) Purge TableWrapper and CoprocessorHConnnection
[ https://issues.apache.org/jira/browse/HBASE-19043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213617#comment-16213617 ] Hudson commented on HBASE-19043: FAILURE: Integrated in Jenkins build HBase-2.0 #721 (See [https://builds.apache.org/job/HBase-2.0/721/]) HBASE-19043 Purge TableWrapper and CoprocessorHConnnection Also purge (stack: rev 9b4caf4b1bd86be77d5661d75ecf16dc83158140) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/token/TestTokenAuthentication.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestOpenTableInCoprocessor.java * (delete) hbase-server/src/main/java/org/apache/hadoop/hbase/client/HTableWrapper.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorHost.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/CoprocessorEnvironment.java * (delete) hbase-server/src/main/java/org/apache/hadoop/hbase/client/CoprocessorHConnection.java * (delete) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestHTableWrapper.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/BaseEnvironment.java > Purge TableWrapper and CoprocessorHConnnection > -- > > Key: HBASE-19043 > URL: https://issues.apache.org/jira/browse/HBASE-19043 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19043.master.001.patch, > HBASE-19043.master.002.patch, HBASE-19043.master.003.patch, > HBASE-19043.master.004.patch, HBASE-19043.master.005.patch, > HBASE-19043.master.006.patch, HBASE-19043.master.007.patch, > HBASE-19043.master.007.patch > > > Repeating note from dev list today which had assent from [~apurtell] and > [~appy]: > {code} > Subject: [DISCUSS] Punt the Coprocessor TableWrapper and > CoprocessorHConnection? > To: HBase Dev List> tl;dr I believe the original intent for TableWrapper and > CoprocessorHConnection can now be gotten elsewhere so we should purge these > classes. > In base CoprocessorEnvironment, there are methods to return a Table > instance. There are none to return an Admin. In our code base, the only > user is the AccessController. Phoenix uses it twice in its Indexer > implementation. > When you call CE#getTable, the default implementation in > BaseEnvironemnt calls HTableWrapper.createWrapper which takes a > BaseEnvironment List in which we keep all Table instances. On shutdown of > the coprocessor, the list is iterated and all tables are closed. > Going via TableWrapper, the class comment says: > * A wrapper for HTable. Can be used to restrict privilege. > * > * Currently it just helps to track tables opened by a Coprocessor and > * facilitate close of them if it is aborted. > * > * We also disallow row locking. > * > * There is nothing now that will stop a coprocessor from using HTable > * objects directly instead of this API, but in the future we intend to > * analyze coprocessor implementations as they are loaded and reject those > * which attempt to use objects and methods outside the Environment > * sandbox. > TableWrapper by my reading delegates all calls to a Table instance with no > interception (there is not rowlocking to override anymore). On open, we do > ensure the Table is up on a CoprocessorHConnection which does the following: > * Connection to an HTable from within a Coprocessor. We can do some > nice tricks since we know we > * are on a regionserver, for instance skipping the full > serialization/deserialization of objects > * when talking to the server. > The above 'trick' is now commonplace in servers as the Master and > RegionServer always make Connections that will short-circuit if an > opportunity. > As I read TableWrapper and CoprocessorHConnection, they were written at > another time when Table construction was heavyweight and Table#close was > not expected of clients and before the introduction of the general > Server-side short-circuit Connection facility. > Unless objection, I think we should purge them. > Writing here in case I'm missing some key facility they provide. > {code} > See > http://search-hadoop.com/m/HBase/YGbb8uCtg26VkBy?subj=+DISCUSS+Punt+the+Coprocessor+TableWrapper+and+CoprocessorHConnection+ > This issue is about removing these classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19043) Purge TableWrapper and CoprocessorHConnnection
[ https://issues.apache.org/jira/browse/HBASE-19043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213601#comment-16213601 ] Hudson commented on HBASE-19043: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3921 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3921/]) HBASE-19043 Purge TableWrapper and CoprocessorHConnnection Also purge (stack: rev d7985412610b612c09cf377ab87963e897c72afa) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/token/TestTokenAuthentication.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorHost.java * (delete) hbase-server/src/main/java/org/apache/hadoop/hbase/client/CoprocessorHConnection.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/BaseEnvironment.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestOpenTableInCoprocessor.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/CoprocessorEnvironment.java * (delete) hbase-server/src/main/java/org/apache/hadoop/hbase/client/HTableWrapper.java * (delete) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestHTableWrapper.java > Purge TableWrapper and CoprocessorHConnnection > -- > > Key: HBASE-19043 > URL: https://issues.apache.org/jira/browse/HBASE-19043 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19043.master.001.patch, > HBASE-19043.master.002.patch, HBASE-19043.master.003.patch, > HBASE-19043.master.004.patch, HBASE-19043.master.005.patch, > HBASE-19043.master.006.patch, HBASE-19043.master.007.patch, > HBASE-19043.master.007.patch > > > Repeating note from dev list today which had assent from [~apurtell] and > [~appy]: > {code} > Subject: [DISCUSS] Punt the Coprocessor TableWrapper and > CoprocessorHConnection? > To: HBase Dev List> tl;dr I believe the original intent for TableWrapper and > CoprocessorHConnection can now be gotten elsewhere so we should purge these > classes. > In base CoprocessorEnvironment, there are methods to return a Table > instance. There are none to return an Admin. In our code base, the only > user is the AccessController. Phoenix uses it twice in its Indexer > implementation. > When you call CE#getTable, the default implementation in > BaseEnvironemnt calls HTableWrapper.createWrapper which takes a > BaseEnvironment List in which we keep all Table instances. On shutdown of > the coprocessor, the list is iterated and all tables are closed. > Going via TableWrapper, the class comment says: > * A wrapper for HTable. Can be used to restrict privilege. > * > * Currently it just helps to track tables opened by a Coprocessor and > * facilitate close of them if it is aborted. > * > * We also disallow row locking. > * > * There is nothing now that will stop a coprocessor from using HTable > * objects directly instead of this API, but in the future we intend to > * analyze coprocessor implementations as they are loaded and reject those > * which attempt to use objects and methods outside the Environment > * sandbox. > TableWrapper by my reading delegates all calls to a Table instance with no > interception (there is not rowlocking to override anymore). On open, we do > ensure the Table is up on a CoprocessorHConnection which does the following: > * Connection to an HTable from within a Coprocessor. We can do some > nice tricks since we know we > * are on a regionserver, for instance skipping the full > serialization/deserialization of objects > * when talking to the server. > The above 'trick' is now commonplace in servers as the Master and > RegionServer always make Connections that will short-circuit if an > opportunity. > As I read TableWrapper and CoprocessorHConnection, they were written at > another time when Table construction was heavyweight and Table#close was > not expected of clients and before the introduction of the general > Server-side short-circuit Connection facility. > Unless objection, I think we should purge them. > Writing here in case I'm missing some key facility they provide. > {code} > See > http://search-hadoop.com/m/HBase/YGbb8uCtg26VkBy?subj=+DISCUSS+Punt+the+Coprocessor+TableWrapper+and+CoprocessorHConnection+ > This issue is about removing these classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19043) Purge TableWrapper and CoprocessorHConnnection
[ https://issues.apache.org/jira/browse/HBASE-19043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16212953#comment-16212953 ] Hadoop QA commented on HBASE-19043: --- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 14m 45s{color} | {color:blue} Docker mode activated. {color} | | {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 0s{color} | {color:green} Patch does not have any anti-patterns. {color} | | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s{color} | {color:green} The patch does not contain any @author tags. {color} | | {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 0s{color} | {color:green} The patch appears to include 4 new or modified test files. {color} | | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 45s{color} | {color:blue} Maven dependency ordering for branch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m 28s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 15s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 4s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 37s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m 12s{color} | {color:green} branch has no errors when building our shaded downstream artifacts. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 30s{color} | {color:green} master passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 5s{color} | {color:green} master passed {color} | | {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 23s{color} | {color:blue} Maven dependency ordering for patch {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m 59s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 8s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 8s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 4s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 34s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s{color} | {color:green} The patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m 30s{color} | {color:green} patch has no errors when building our shaded downstream artifacts. {color} | | {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 38m 29s{color} | {color:green} Patch does not cause any errors with Hadoop 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 36s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 54s{color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 43s{color} | {color:green} hbase-client in the patch passed. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red}100m 34s{color} | {color:red} hbase-server in the patch failed. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 26s{color} | {color:green} The patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black}190m 41s{color} | {color:black} {color} | \\ \\ || Reason || Tests || | Failed junit tests | hadoop.hbase.client.TestBlockEvictionFromClient | \\ \\ || Subsystem || Report/Notes || | Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:af479c5 | | JIRA Issue | HBASE-19043 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12893187/HBASE-19043.master.007.patch | | Optional Tests | asflicense shadedjars javac javadoc unit findbugs hadoopcheck hbaseanti checkstyle compile | | uname | Linux 9d78eda4ec7b 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11 12:48:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality |
[jira] [Commented] (HBASE-19043) Purge TableWrapper and CoprocessorHConnnection
[ https://issues.apache.org/jira/browse/HBASE-19043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16212227#comment-16212227 ] stack commented on HBASE-19043: --- .008 adds TODO suggested by [~anoop.hbase] where we could do direct invocations against ACL table. > Purge TableWrapper and CoprocessorHConnnection > -- > > Key: HBASE-19043 > URL: https://issues.apache.org/jira/browse/HBASE-19043 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19043.master.001.patch, > HBASE-19043.master.002.patch, HBASE-19043.master.003.patch, > HBASE-19043.master.004.patch, HBASE-19043.master.005.patch, > HBASE-19043.master.006.patch, HBASE-19043.master.007.patch > > > Repeating note from dev list today which had assent from [~apurtell] and > [~appy]: > {code} > Subject: [DISCUSS] Punt the Coprocessor TableWrapper and > CoprocessorHConnection? > To: HBase Dev List> tl;dr I believe the original intent for TableWrapper and > CoprocessorHConnection can now be gotten elsewhere so we should purge these > classes. > In base CoprocessorEnvironment, there are methods to return a Table > instance. There are none to return an Admin. In our code base, the only > user is the AccessController. Phoenix uses it twice in its Indexer > implementation. > When you call CE#getTable, the default implementation in > BaseEnvironemnt calls HTableWrapper.createWrapper which takes a > BaseEnvironment List in which we keep all Table instances. On shutdown of > the coprocessor, the list is iterated and all tables are closed. > Going via TableWrapper, the class comment says: > * A wrapper for HTable. Can be used to restrict privilege. > * > * Currently it just helps to track tables opened by a Coprocessor and > * facilitate close of them if it is aborted. > * > * We also disallow row locking. > * > * There is nothing now that will stop a coprocessor from using HTable > * objects directly instead of this API, but in the future we intend to > * analyze coprocessor implementations as they are loaded and reject those > * which attempt to use objects and methods outside the Environment > * sandbox. > TableWrapper by my reading delegates all calls to a Table instance with no > interception (there is not rowlocking to override anymore). On open, we do > ensure the Table is up on a CoprocessorHConnection which does the following: > * Connection to an HTable from within a Coprocessor. We can do some > nice tricks since we know we > * are on a regionserver, for instance skipping the full > serialization/deserialization of objects > * when talking to the server. > The above 'trick' is now commonplace in servers as the Master and > RegionServer always make Connections that will short-circuit if an > opportunity. > As I read TableWrapper and CoprocessorHConnection, they were written at > another time when Table construction was heavyweight and Table#close was > not expected of clients and before the introduction of the general > Server-side short-circuit Connection facility. > Unless objection, I think we should purge them. > Writing here in case I'm missing some key facility they provide. > {code} > See > http://search-hadoop.com/m/HBase/YGbb8uCtg26VkBy?subj=+DISCUSS+Punt+the+Coprocessor+TableWrapper+and+CoprocessorHConnection+ > This issue is about removing these classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19043) Purge TableWrapper and CoprocessorHConnnection
[ https://issues.apache.org/jira/browse/HBASE-19043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16211624#comment-16211624 ] Hadoop QA commented on HBASE-19043: --- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s{color} | {color:blue} Docker mode activated. {color} | | {color:red}-1{color} | {color:red} docker {color} | {color:red} 0m 19s{color} | {color:red} Docker failed to build yetus/hbase:4a7b430. {color} | \\ \\ || Subsystem || Report/Notes || | JIRA Issue | HBASE-19043 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12893100/HBASE-19043.master.005.patch | | Console output | https://builds.apache.org/job/PreCommit-HBASE-Build/9232/console | | Powered by | Apache Yetus 0.4.0 http://yetus.apache.org | This message was automatically generated. > Purge TableWrapper and CoprocessorHConnnection > -- > > Key: HBASE-19043 > URL: https://issues.apache.org/jira/browse/HBASE-19043 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19043.master.001.patch, > HBASE-19043.master.002.patch, HBASE-19043.master.003.patch, > HBASE-19043.master.004.patch, HBASE-19043.master.005.patch > > > Repeating note from dev list today which had assent from [~apurtell] and > [~appy]: > {code} > Subject: [DISCUSS] Punt the Coprocessor TableWrapper and > CoprocessorHConnection? > To: HBase Dev List> tl;dr I believe the original intent for TableWrapper and > CoprocessorHConnection can now be gotten elsewhere so we should purge these > classes. > In base CoprocessorEnvironment, there are methods to return a Table > instance. There are none to return an Admin. In our code base, the only > user is the AccessController. Phoenix uses it twice in its Indexer > implementation. > When you call CE#getTable, the default implementation in > BaseEnvironemnt calls HTableWrapper.createWrapper which takes a > BaseEnvironment List in which we keep all Table instances. On shutdown of > the coprocessor, the list is iterated and all tables are closed. > Going via TableWrapper, the class comment says: > * A wrapper for HTable. Can be used to restrict privilege. > * > * Currently it just helps to track tables opened by a Coprocessor and > * facilitate close of them if it is aborted. > * > * We also disallow row locking. > * > * There is nothing now that will stop a coprocessor from using HTable > * objects directly instead of this API, but in the future we intend to > * analyze coprocessor implementations as they are loaded and reject those > * which attempt to use objects and methods outside the Environment > * sandbox. > TableWrapper by my reading delegates all calls to a Table instance with no > interception (there is not rowlocking to override anymore). On open, we do > ensure the Table is up on a CoprocessorHConnection which does the following: > * Connection to an HTable from within a Coprocessor. We can do some > nice tricks since we know we > * are on a regionserver, for instance skipping the full > serialization/deserialization of objects > * when talking to the server. > The above 'trick' is now commonplace in servers as the Master and > RegionServer always make Connections that will short-circuit if an > opportunity. > As I read TableWrapper and CoprocessorHConnection, they were written at > another time when Table construction was heavyweight and Table#close was > not expected of clients and before the introduction of the general > Server-side short-circuit Connection facility. > Unless objection, I think we should purge them. > Writing here in case I'm missing some key facility they provide. > {code} > See > http://search-hadoop.com/m/HBase/YGbb8uCtg26VkBy?subj=+DISCUSS+Punt+the+Coprocessor+TableWrapper+and+CoprocessorHConnection+ > This issue is about removing these classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19043) Purge TableWrapper and CoprocessorHConnnection
[ https://issues.apache.org/jira/browse/HBASE-19043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16211595#comment-16211595 ] stack commented on HBASE-19043: --- .005 addresses more [~anoop.hbase] review; I'd missed an arg in translation to new mode of doing tables. > Purge TableWrapper and CoprocessorHConnnection > -- > > Key: HBASE-19043 > URL: https://issues.apache.org/jira/browse/HBASE-19043 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19043.master.001.patch, > HBASE-19043.master.002.patch, HBASE-19043.master.003.patch, > HBASE-19043.master.004.patch, HBASE-19043.master.005.patch > > > Repeating note from dev list today which had assent from [~apurtell] and > [~appy]: > {code} > Subject: [DISCUSS] Punt the Coprocessor TableWrapper and > CoprocessorHConnection? > To: HBase Dev List> tl;dr I believe the original intent for TableWrapper and > CoprocessorHConnection can now be gotten elsewhere so we should purge these > classes. > In base CoprocessorEnvironment, there are methods to return a Table > instance. There are none to return an Admin. In our code base, the only > user is the AccessController. Phoenix uses it twice in its Indexer > implementation. > When you call CE#getTable, the default implementation in > BaseEnvironemnt calls HTableWrapper.createWrapper which takes a > BaseEnvironment List in which we keep all Table instances. On shutdown of > the coprocessor, the list is iterated and all tables are closed. > Going via TableWrapper, the class comment says: > * A wrapper for HTable. Can be used to restrict privilege. > * > * Currently it just helps to track tables opened by a Coprocessor and > * facilitate close of them if it is aborted. > * > * We also disallow row locking. > * > * There is nothing now that will stop a coprocessor from using HTable > * objects directly instead of this API, but in the future we intend to > * analyze coprocessor implementations as they are loaded and reject those > * which attempt to use objects and methods outside the Environment > * sandbox. > TableWrapper by my reading delegates all calls to a Table instance with no > interception (there is not rowlocking to override anymore). On open, we do > ensure the Table is up on a CoprocessorHConnection which does the following: > * Connection to an HTable from within a Coprocessor. We can do some > nice tricks since we know we > * are on a regionserver, for instance skipping the full > serialization/deserialization of objects > * when talking to the server. > The above 'trick' is now commonplace in servers as the Master and > RegionServer always make Connections that will short-circuit if an > opportunity. > As I read TableWrapper and CoprocessorHConnection, they were written at > another time when Table construction was heavyweight and Table#close was > not expected of clients and before the introduction of the general > Server-side short-circuit Connection facility. > Unless objection, I think we should purge them. > Writing here in case I'm missing some key facility they provide. > {code} > See > http://search-hadoop.com/m/HBase/YGbb8uCtg26VkBy?subj=+DISCUSS+Punt+the+Coprocessor+TableWrapper+and+CoprocessorHConnection+ > This issue is about removing these classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19043) Purge TableWrapper and CoprocessorHConnnection
[ https://issues.apache.org/jira/browse/HBASE-19043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16211462#comment-16211462 ] Hadoop QA commented on HBASE-19043: --- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s{color} | {color:blue} Docker mode activated. {color} | | {color:red}-1{color} | {color:red} docker {color} | {color:red} 0m 20s{color} | {color:red} Docker failed to build yetus/hbase:4a7b430. {color} | \\ \\ || Subsystem || Report/Notes || | JIRA Issue | HBASE-19043 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12893083/HBASE-19043.master.004.patch | | Console output | https://builds.apache.org/job/PreCommit-HBASE-Build/9225/console | | Powered by | Apache Yetus 0.4.0 http://yetus.apache.org | This message was automatically generated. > Purge TableWrapper and CoprocessorHConnnection > -- > > Key: HBASE-19043 > URL: https://issues.apache.org/jira/browse/HBASE-19043 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19043.master.001.patch, > HBASE-19043.master.002.patch, HBASE-19043.master.003.patch, > HBASE-19043.master.004.patch > > > Repeating note from dev list today which had assent from [~apurtell] and > [~appy]: > {code} > Subject: [DISCUSS] Punt the Coprocessor TableWrapper and > CoprocessorHConnection? > To: HBase Dev List> tl;dr I believe the original intent for TableWrapper and > CoprocessorHConnection can now be gotten elsewhere so we should purge these > classes. > In base CoprocessorEnvironment, there are methods to return a Table > instance. There are none to return an Admin. In our code base, the only > user is the AccessController. Phoenix uses it twice in its Indexer > implementation. > When you call CE#getTable, the default implementation in > BaseEnvironemnt calls HTableWrapper.createWrapper which takes a > BaseEnvironment List in which we keep all Table instances. On shutdown of > the coprocessor, the list is iterated and all tables are closed. > Going via TableWrapper, the class comment says: > * A wrapper for HTable. Can be used to restrict privilege. > * > * Currently it just helps to track tables opened by a Coprocessor and > * facilitate close of them if it is aborted. > * > * We also disallow row locking. > * > * There is nothing now that will stop a coprocessor from using HTable > * objects directly instead of this API, but in the future we intend to > * analyze coprocessor implementations as they are loaded and reject those > * which attempt to use objects and methods outside the Environment > * sandbox. > TableWrapper by my reading delegates all calls to a Table instance with no > interception (there is not rowlocking to override anymore). On open, we do > ensure the Table is up on a CoprocessorHConnection which does the following: > * Connection to an HTable from within a Coprocessor. We can do some > nice tricks since we know we > * are on a regionserver, for instance skipping the full > serialization/deserialization of objects > * when talking to the server. > The above 'trick' is now commonplace in servers as the Master and > RegionServer always make Connections that will short-circuit if an > opportunity. > As I read TableWrapper and CoprocessorHConnection, they were written at > another time when Table construction was heavyweight and Table#close was > not expected of clients and before the introduction of the general > Server-side short-circuit Connection facility. > Unless objection, I think we should purge them. > Writing here in case I'm missing some key facility they provide. > {code} > See > http://search-hadoop.com/m/HBase/YGbb8uCtg26VkBy?subj=+DISCUSS+Punt+the+Coprocessor+TableWrapper+and+CoprocessorHConnection+ > This issue is about removing these classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19043) Purge TableWrapper and CoprocessorHConnnection
[ https://issues.apache.org/jira/browse/HBASE-19043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16211438#comment-16211438 ] stack commented on HBASE-19043: --- .003 addresses great review by [~anoop.hbase] in rb. > Purge TableWrapper and CoprocessorHConnnection > -- > > Key: HBASE-19043 > URL: https://issues.apache.org/jira/browse/HBASE-19043 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19043.master.001.patch, > HBASE-19043.master.002.patch, HBASE-19043.master.003.patch > > > Repeating note from dev list today which had assent from [~apurtell] and > [~appy]: > {code} > Subject: [DISCUSS] Punt the Coprocessor TableWrapper and > CoprocessorHConnection? > To: HBase Dev List> tl;dr I believe the original intent for TableWrapper and > CoprocessorHConnection can now be gotten elsewhere so we should purge these > classes. > In base CoprocessorEnvironment, there are methods to return a Table > instance. There are none to return an Admin. In our code base, the only > user is the AccessController. Phoenix uses it twice in its Indexer > implementation. > When you call CE#getTable, the default implementation in > BaseEnvironemnt calls HTableWrapper.createWrapper which takes a > BaseEnvironment List in which we keep all Table instances. On shutdown of > the coprocessor, the list is iterated and all tables are closed. > Going via TableWrapper, the class comment says: > * A wrapper for HTable. Can be used to restrict privilege. > * > * Currently it just helps to track tables opened by a Coprocessor and > * facilitate close of them if it is aborted. > * > * We also disallow row locking. > * > * There is nothing now that will stop a coprocessor from using HTable > * objects directly instead of this API, but in the future we intend to > * analyze coprocessor implementations as they are loaded and reject those > * which attempt to use objects and methods outside the Environment > * sandbox. > TableWrapper by my reading delegates all calls to a Table instance with no > interception (there is not rowlocking to override anymore). On open, we do > ensure the Table is up on a CoprocessorHConnection which does the following: > * Connection to an HTable from within a Coprocessor. We can do some > nice tricks since we know we > * are on a regionserver, for instance skipping the full > serialization/deserialization of objects > * when talking to the server. > The above 'trick' is now commonplace in servers as the Master and > RegionServer always make Connections that will short-circuit if an > opportunity. > As I read TableWrapper and CoprocessorHConnection, they were written at > another time when Table construction was heavyweight and Table#close was > not expected of clients and before the introduction of the general > Server-side short-circuit Connection facility. > Unless objection, I think we should purge them. > Writing here in case I'm missing some key facility they provide. > {code} > See > http://search-hadoop.com/m/HBase/YGbb8uCtg26VkBy?subj=+DISCUSS+Punt+the+Coprocessor+TableWrapper+and+CoprocessorHConnection+ > This issue is about removing these classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19043) Purge TableWrapper and CoprocessorHConnnection
[ https://issues.apache.org/jira/browse/HBASE-19043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16211417#comment-16211417 ] Hadoop QA commented on HBASE-19043: --- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s{color} | {color:blue} Docker mode activated. {color} | | {color:red}-1{color} | {color:red} docker {color} | {color:red} 0m 19s{color} | {color:red} Docker failed to build yetus/hbase:4a7b430. {color} | \\ \\ || Subsystem || Report/Notes || | JIRA Issue | HBASE-19043 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12893080/HBASE-19043.master.002.patch | | Console output | https://builds.apache.org/job/PreCommit-HBASE-Build/9224/console | | Powered by | Apache Yetus 0.4.0 http://yetus.apache.org | This message was automatically generated. > Purge TableWrapper and CoprocessorHConnnection > -- > > Key: HBASE-19043 > URL: https://issues.apache.org/jira/browse/HBASE-19043 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19043.master.001.patch, > HBASE-19043.master.002.patch > > > Repeating note from dev list today which had assent from [~apurtell] and > [~appy]: > {code} > Subject: [DISCUSS] Punt the Coprocessor TableWrapper and > CoprocessorHConnection? > To: HBase Dev List> tl;dr I believe the original intent for TableWrapper and > CoprocessorHConnection can now be gotten elsewhere so we should purge these > classes. > In base CoprocessorEnvironment, there are methods to return a Table > instance. There are none to return an Admin. In our code base, the only > user is the AccessController. Phoenix uses it twice in its Indexer > implementation. > When you call CE#getTable, the default implementation in > BaseEnvironemnt calls HTableWrapper.createWrapper which takes a > BaseEnvironment List in which we keep all Table instances. On shutdown of > the coprocessor, the list is iterated and all tables are closed. > Going via TableWrapper, the class comment says: > * A wrapper for HTable. Can be used to restrict privilege. > * > * Currently it just helps to track tables opened by a Coprocessor and > * facilitate close of them if it is aborted. > * > * We also disallow row locking. > * > * There is nothing now that will stop a coprocessor from using HTable > * objects directly instead of this API, but in the future we intend to > * analyze coprocessor implementations as they are loaded and reject those > * which attempt to use objects and methods outside the Environment > * sandbox. > TableWrapper by my reading delegates all calls to a Table instance with no > interception (there is not rowlocking to override anymore). On open, we do > ensure the Table is up on a CoprocessorHConnection which does the following: > * Connection to an HTable from within a Coprocessor. We can do some > nice tricks since we know we > * are on a regionserver, for instance skipping the full > serialization/deserialization of objects > * when talking to the server. > The above 'trick' is now commonplace in servers as the Master and > RegionServer always make Connections that will short-circuit if an > opportunity. > As I read TableWrapper and CoprocessorHConnection, they were written at > another time when Table construction was heavyweight and Table#close was > not expected of clients and before the introduction of the general > Server-side short-circuit Connection facility. > Unless objection, I think we should purge them. > Writing here in case I'm missing some key facility they provide. > {code} > See > http://search-hadoop.com/m/HBase/YGbb8uCtg26VkBy?subj=+DISCUSS+Punt+the+Coprocessor+TableWrapper+and+CoprocessorHConnection+ > This issue is about removing these classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19043) Purge TableWrapper and CoprocessorHConnnection
[ https://issues.apache.org/jira/browse/HBASE-19043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16210566#comment-16210566 ] Hadoop QA commented on HBASE-19043: --- | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s{color} | {color:blue} Docker mode activated. {color} | | {color:red}-1{color} | {color:red} docker {color} | {color:red} 0m 18s{color} | {color:red} Docker failed to build yetus/hbase:5d60123. {color} | \\ \\ || Subsystem || Report/Notes || | JIRA Issue | HBASE-19043 | | JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12892977/HBASE-19043.master.001.patch | | Console output | https://builds.apache.org/job/PreCommit-HBASE-Build/9203/console | | Powered by | Apache Yetus 0.4.0 http://yetus.apache.org | This message was automatically generated. > Purge TableWrapper and CoprocessorHConnnection > -- > > Key: HBASE-19043 > URL: https://issues.apache.org/jira/browse/HBASE-19043 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19043.master.001.patch > > > Repeating note from dev list today which had assent from [~apurtell] and > [~appy]: > {code} > Subject: [DISCUSS] Punt the Coprocessor TableWrapper and > CoprocessorHConnection? > To: HBase Dev List> tl;dr I believe the original intent for TableWrapper and > CoprocessorHConnection can now be gotten elsewhere so we should purge these > classes. > In base CoprocessorEnvironment, there are methods to return a Table > instance. There are none to return an Admin. In our code base, the only > user is the AccessController. Phoenix uses it twice in its Indexer > implementation. > When you call CE#getTable, the default implementation in > BaseEnvironemnt calls HTableWrapper.createWrapper which takes a > BaseEnvironment List in which we keep all Table instances. On shutdown of > the coprocessor, the list is iterated and all tables are closed. > Going via TableWrapper, the class comment says: > * A wrapper for HTable. Can be used to restrict privilege. > * > * Currently it just helps to track tables opened by a Coprocessor and > * facilitate close of them if it is aborted. > * > * We also disallow row locking. > * > * There is nothing now that will stop a coprocessor from using HTable > * objects directly instead of this API, but in the future we intend to > * analyze coprocessor implementations as they are loaded and reject those > * which attempt to use objects and methods outside the Environment > * sandbox. > TableWrapper by my reading delegates all calls to a Table instance with no > interception (there is not rowlocking to override anymore). On open, we do > ensure the Table is up on a CoprocessorHConnection which does the following: > * Connection to an HTable from within a Coprocessor. We can do some > nice tricks since we know we > * are on a regionserver, for instance skipping the full > serialization/deserialization of objects > * when talking to the server. > The above 'trick' is now commonplace in servers as the Master and > RegionServer always make Connections that will short-circuit if an > opportunity. > As I read TableWrapper and CoprocessorHConnection, they were written at > another time when Table construction was heavyweight and Table#close was > not expected of clients and before the introduction of the general > Server-side short-circuit Connection facility. > Unless objection, I think we should purge them. > Writing here in case I'm missing some key facility they provide. > {code} > See > http://search-hadoop.com/m/HBase/YGbb8uCtg26VkBy?subj=+DISCUSS+Punt+the+Coprocessor+TableWrapper+and+CoprocessorHConnection+ > This issue is about removing these classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19043) Purge TableWrapper and CoprocessorHConnnection
[ https://issues.apache.org/jira/browse/HBASE-19043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16210559#comment-16210559 ] stack commented on HBASE-19043: --- .001 is mostly removals. > Purge TableWrapper and CoprocessorHConnnection > -- > > Key: HBASE-19043 > URL: https://issues.apache.org/jira/browse/HBASE-19043 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19043.master.001.patch > > > Repeating note from dev list today which had assent from [~apurtell] and > [~appy]: > {code} > Subject: [DISCUSS] Punt the Coprocessor TableWrapper and > CoprocessorHConnection? > To: HBase Dev List> tl;dr I believe the original intent for TableWrapper and > CoprocessorHConnection can now be gotten elsewhere so we should purge these > classes. > In base CoprocessorEnvironment, there are methods to return a Table > instance. There are none to return an Admin. In our code base, the only > user is the AccessController. Phoenix uses it twice in its Indexer > implementation. > When you call CE#getTable, the default implementation in > BaseEnvironemnt calls HTableWrapper.createWrapper which takes a > BaseEnvironment List in which we keep all Table instances. On shutdown of > the coprocessor, the list is iterated and all tables are closed. > Going via TableWrapper, the class comment says: > * A wrapper for HTable. Can be used to restrict privilege. > * > * Currently it just helps to track tables opened by a Coprocessor and > * facilitate close of them if it is aborted. > * > * We also disallow row locking. > * > * There is nothing now that will stop a coprocessor from using HTable > * objects directly instead of this API, but in the future we intend to > * analyze coprocessor implementations as they are loaded and reject those > * which attempt to use objects and methods outside the Environment > * sandbox. > TableWrapper by my reading delegates all calls to a Table instance with no > interception (there is not rowlocking to override anymore). On open, we do > ensure the Table is up on a CoprocessorHConnection which does the following: > * Connection to an HTable from within a Coprocessor. We can do some > nice tricks since we know we > * are on a regionserver, for instance skipping the full > serialization/deserialization of objects > * when talking to the server. > The above 'trick' is now commonplace in servers as the Master and > RegionServer always make Connections that will short-circuit if an > opportunity. > As I read TableWrapper and CoprocessorHConnection, they were written at > another time when Table construction was heavyweight and Table#close was > not expected of clients and before the introduction of the general > Server-side short-circuit Connection facility. > Unless objection, I think we should purge them. > Writing here in case I'm missing some key facility they provide. > {code} > See > http://search-hadoop.com/m/HBase/YGbb8uCtg26VkBy?subj=+DISCUSS+Punt+the+Coprocessor+TableWrapper+and+CoprocessorHConnection+ > This issue is about removing these classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)