Re: [DISCUSS] Punt the Coprocessor TableWrapper and CoprocessorHConnection?
HBASE-19043 S On Wed, Oct 18, 2017 at 3:29 PM, Andrew Purtell wrote: > > I remember Andrew saying same thing about CoprocessorEnvironment# > getTable > functions during the review of HBASE-17732, that we should get rid of them > and let CP do their own table resource management like all other things. > > Yes > > > The above 'trick' is now commonplace in servers as the Master and > RegionServer > always make Connections that will short-circuit if an opportunity > > No need for CoprocessorHConnection, then. > > > > On Wed, Oct 18, 2017 at 3:12 PM, Apekshit Sharma > wrote: > > > +1 > > I remember Andrew saying same thing about CoprocessorEnvironment# > getTable > > functions during the review of HBASE-17732, that we should get rid of > them > > and let CP do their own table resource management like all other things. > > > > On Wed, Oct 18, 2017 at 2:45 PM, Stack wrote: > > > > > 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. > > > > > > Thanks, > > > St.Ack > > > > > > > > > > > -- > > > > -- Appy > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands >- A23, Crosstalk >
[jira] [Created] (HBASE-19043) Purge TableWrapper and CoprocessorHConnnection
stack created HBASE-19043:
-
Summary: 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
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)
Re: [DISCUSS] Help adding a check for localization edge cases in our current test suites?
File an issue and post what to do there? I think there are plenty of Chinese contributors in our community, although some of them may also use English locale :) 2017-10-18 22:57 GMT+08:00 Sean Busbey : > Hi folks! > > This comment from Chia-Ping on HBASE-19020 has me thinking: > > > The TestXmlParsing is a flaky test in my jenkins, because the error > message from my machine is in Chinese. > > I wonder how many more of our tests rely incorrectly on the > localization settings being set to American English. > > Would any of our folks who normally work with a locale that isn't > American English be willing to help me get a test set up (maybe in our > nightly runs?) that tries to catch these kinds of issues? >
Re: [INFO] Failing Precommit Builds - HBASE-19042
Thanks for the heads up and thanks to the folks digging in on this. Great find Peter! On Oct 18, 2017 8:52 PM, "Mike Drob" wrote: > Hi devs, > > Wanted to send a quick note, since some of you have noticed our precommit > failing with mysterious docker errors. > > Our Peter has diagnosed this as Oracle changing their download URL when > releasing the latest update of Java 8. There's a few different proposed > solutions here, the final fix will be tracked in > https://issues.apache.org/jira/browse/HBASE-19042 > > We understand that this is frustrating for folks trying to submit patches > currently, and appreciate your patience while waiting for a solution. If > you have questions, comments, concerns, or suggestions, please reply here > or on the JIRA. > > Thanks, > Mike >
[INFO] Failing Precommit Builds - HBASE-19042
Hi devs, Wanted to send a quick note, since some of you have noticed our precommit failing with mysterious docker errors. Our Peter has diagnosed this as Oracle changing their download URL when releasing the latest update of Java 8. There's a few different proposed solutions here, the final fix will be tracked in https://issues.apache.org/jira/browse/HBASE-19042 We understand that this is frustrating for folks trying to submit patches currently, and appreciate your patience while waiting for a solution. If you have questions, comments, concerns, or suggestions, please reply here or on the JIRA. Thanks, Mike
Re: [DISCUSS] Punt the Coprocessor TableWrapper and CoprocessorHConnection?
> I remember Andrew saying same thing about CoprocessorEnvironment#getTable functions during the review of HBASE-17732, that we should get rid of them and let CP do their own table resource management like all other things. Yes > The above 'trick' is now commonplace in servers as the Master and RegionServer always make Connections that will short-circuit if an opportunity No need for CoprocessorHConnection, then. On Wed, Oct 18, 2017 at 3:12 PM, Apekshit Sharma wrote: > +1 > I remember Andrew saying same thing about CoprocessorEnvironment#getTable > functions during the review of HBASE-17732, that we should get rid of them > and let CP do their own table resource management like all other things. > > On Wed, Oct 18, 2017 at 2:45 PM, Stack wrote: > > > 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. > > > > Thanks, > > St.Ack > > > > > > -- > > -- Appy > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
Re: [DISCUSS] Punt the Coprocessor TableWrapper and CoprocessorHConnection?
+1 I remember Andrew saying same thing about CoprocessorEnvironment#getTable functions during the review of HBASE-17732, that we should get rid of them and let CP do their own table resource management like all other things. On Wed, Oct 18, 2017 at 2:45 PM, Stack wrote: > 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. > > Thanks, > St.Ack > -- -- Appy
[DISCUSS] Punt the Coprocessor TableWrapper and CoprocessorHConnection?
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. Thanks, St.Ack
[jira] [Created] (HBASE-19042) Change Oracle JDK8 version to 8u151
Peter Somogyi created HBASE-19042:
-
Summary: Change Oracle JDK8 version to 8u151
Key: HBASE-19042
URL: https://issues.apache.org/jira/browse/HBASE-19042
Project: HBase
Issue Type: Bug
Components: build
Reporter: Peter Somogyi
Priority: Blocker
Precommit job fails to install Oracle Java 8 to docker image which is due to
Oracle's new Java version, 8u151.
As this thread point out we probably need to upgrade to latest java 8 version:
https://ubuntuforums.org/showthread.php?t=2374686
{code}
06:45:14 Setting up java-common (0.51) ...
06:45:14 Setting up oracle-java8-installer (8u144-1~webupd8~0) ...
06:45:14 [91mNo /var/cache/oracle-jdk8-installer/wgetrc file found.
06:45:14 Creating /var/cache/oracle-jdk8-installer/wgetrc and
06:45:14 using default oracle-java8-installer wgetrc settings for it.
06:45:14 Downloading Oracle Java 8...
06:45:14 [0m[91m--2017-10-18 13:45:14--
http://download.oracle.com/otn-pub/java/jdk/8u144-b01/090f390dda5b47b9b721c7dfaa008135/jdk-8u144-linux-x64.tar.gz
06:45:14 Resolving download.oracle.com (download.oracle.com)...
[0m[91m23.59.189.81, 23.59.189.91
06:45:14 Connecting to download.oracle.com
(download.oracle.com)|23.59.189.81|:80... [0m[91mconnected.
06:45:14 HTTP request sent, awaiting response... [0m[91m302 Moved Temporarily
06:45:14 Location:
https://edelivery.oracle.com/otn-pub/java/jdk/8u144-b01/090f390dda5b47b9b721c7dfaa008135/jdk-8u144-linux-x64.tar.gz
[following]
06:45:14 --2017-10-18 13:45:14--
https://edelivery.oracle.com/otn-pub/java/jdk/8u144-b01/090f390dda5b47b9b721c7dfaa008135/jdk-8u144-linux-x64.tar.gz
06:45:14 [0m[91mResolving edelivery.oracle.com (edelivery.oracle.com)...
[0m[91m23.39.16.136, 2600:1409:a:39e::2d3e, 2600:1409:a:39c::2d3e
06:45:14 Connecting to edelivery.oracle.com
(edelivery.oracle.com)|23.39.16.136|:443... [0m[91mconnected.
06:45:14 [0m[91mHTTP request sent, awaiting response... [0m[91m302 Moved
Temporarily
06:45:14 Location:
http://download.oracle.com/otn-pub/java/jdk/8u144-b01/090f390dda5b47b9b721c7dfaa008135/jdk-8u144-linux-x64.tar.gz?AuthParam=1508334434_7da3c9610b0368a45f954cd47d91121c
[following]
06:45:14 --2017-10-18 13:45:14--
http://download.oracle.com/otn-pub/java/jdk/8u144-b01/090f390dda5b47b9b721c7dfaa008135/jdk-8u144-linux-x64.tar.gz?AuthParam=1508334434_7da3c9610b0368a45f954cd47d91121c
06:45:14 Connecting to download.oracle.com
(download.oracle.com)|23.59.189.81|:80... [0m[91mconnected.
06:45:14 HTTP request sent, awaiting response... [0m[91m404 Not Found
06:45:14 2017-10-18 13:45:14 ERROR 404: Not Found.
06:45:14
06:45:14 [0m[91mdownload failed
06:45:14 Oracle JDK 8 is NOT installed.
06:45:14 [0m[91mdpkg: error processing package oracle-java8-installer
(--configure):
06:45:14 subprocess installed post-installation script returned error exit
status 1
06:45:14 [0m[91mErrors were encountered while processing:
06:45:14 oracle-java8-installer
06:45:29 [0m[91mE: Sub-process /usr/bin/dpkg returned an error code (1)
06:45:29 [0mThe command '/bin/sh -c apt-get -q update && apt-get -q install
--no-install-recommends -y oracle-java8-installer' returned a non-zero code: 100
06:45:29
06:45:29 Total Elapsed time: 3m 19s
06:45:29
06:45:29 ERROR: Docker failed to build image.
{code}
Workaround mentioned in the forum post:
{code}
sudo sed -i 's|JAVA_VERSION=8u144|JAVA_VERSION=8u152|' oracle-java8-installer.*
sudo sed -i
's|PARTNER_URL=http://download.oracle.com/otn-pub/java/jdk/8u144-b01/090f390dda5b47b9b721c7dfaa008135/|PARTNER_URL=http://download.oracle.com/otn-pub/java/jdk/8u152-b16/aa0333dd3019491ca4f6ddbe78cdb6d0/|'
oracle-java8-installer.*
sudo sed -i
's|SHA256SUM_TGZ="e8a341ce566f32c3d06f6d0f0eeea9a0f434f538d22af949ae58bc86f2eeaae4"|SHA256SUM_TGZ="218b3b340c3f6d05d940b817d0270dfe0cfd657a636bad074dcabe0c111961bf"|'
oracle-java8-installer.*
sudo sed -i 's|J_DIR=jdk1.8.0_144|J_DIR=jdk1.8.0_152|' oracle-java8-installer.*
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (HBASE-19040) CP service exec broken for older clients after PB namespace addition
[
https://issues.apache.org/jira/browse/HBASE-19040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved HBASE-19040.
Resolution: Duplicate
HBASE-15741
> CP service exec broken for older clients after PB namespace addition
>
>
> Key: HBASE-19040
> URL: https://issues.apache.org/jira/browse/HBASE-19040
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors, Protobufs
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: 2.0.0-alpha-4, 1.3.3
>
>
> Was investigating an upgrade failure at dayjob. The "old" version did not
> include HBASE-14077 while the new version did include HBASE-14077.
> After the servers have been upgraded, the clients which try to execute CP
> calls will begin to fail with a message such as:
> {noformat}
> $ hbase(main):001:0> user_permission
> User
> Namespace,Table,Family,Qualifier:Permission
> ERROR: org.apache.hadoop.hbase.exceptions.UnknownProtocolException: No
> registered coprocessor service found for name AccessControlService in region
> hbase:acl,,1508228211139.0ef76894681187f0ef958e78aed64d30.
> at
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7829)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1980)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1962)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32389)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2150)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:187)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:167)
> {noformat}
> The funny part is that the Region actually has a CP registered under the name
> {{hbase.pb.AccessControlService}}, but the client asks for one under
> {{AccessControlService}}.
> I think the easy fix is to deploy the CP under both names while HBase
> services support client backwards compatibility with 1.x clients.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (HBASE-19037) BLOCKCACHE not work in console
[
https://issues.apache.org/jira/browse/HBASE-19037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey resolved HBASE-19037.
-
Resolution: Invalid
Please take these kinds of questions to the [user@hbase mailing
list|https://lists.apache.org/list.html?u...@hbase.apache.org].
> BLOCKCACHE not work in console
> --
>
> Key: HBASE-19037
> URL: https://issues.apache.org/jira/browse/HBASE-19037
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.2.6
>Reporter: Александр
>
> I'm testing the speed. At the time of the request, I know part of the key.
> ```
> scan 'id_bank',
> {STARTROW=>"24168557"+"\137",STOPROW=>"24168557"+"\177",COLUMNS => ['high',
> 'low'], BLOCKCACHE => 'true'}
> ```
> When I run the scan, the response returns a short time, and if I make a
> second request, the answer is already returned quickly, why?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19041) Precommit job that lets contributors know if their patch can be cleanly backported to targetted branches
Sean Busbey created HBASE-19041:
---
Summary: Precommit job that lets contributors know if their patch
can be cleanly backported to targetted branches
Key: HBASE-19041
URL: https://issues.apache.org/jira/browse/HBASE-19041
Project: HBase
Issue Type: New Feature
Components: test
Reporter: Sean Busbey
Priority: Minor
I'd like a precommit job that can comment on a jira to let contributors know
when they'll need to provide a branch-specific patch. For example, when the
fixVersion is set to 1.2+ and the master patch can't be cherry-picked to 1.3,
we'd have a comment like:
{quote}
The provided patch 'HBASE-12345.0.patch' cleanly backports from 'master' to
'branch-2', and 'branch-1'.
The provided patch 'HBASE-12345.0.patch' fails to backport to 'branch-1.3' with
a failure to cherry-pick. Details can be found at
http://builds.a.o/job/HBase-Some-Job/1234/artifacts/backport-1.3-report.log.
Contributor, you will likely be asked to provide a 'branch-1.3' specific
version of your patch. Most likely you will need to locally use these commands
(presuming your original patch is on a feature branch named after this jira,
'HBASE-12345') and resolve any conflicts:
{code}
$> git checkout origin/branch-1.3 -b HBASE-12345-branch-1.3
$> git cherry-pick HBASE-12345
... conflict should be here ...
{code}
Once you have resolved the conflict, please generate a patch and attach it
here, following the branch-specific naming guidelines.
{code}
$> git format-patch --stdout origin/branch-1.3 >
/some/path/to/patches/HBASE-12345-branch-1.3.v0.patch
{code}
{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19040) CP service exec broken for older clients after PB namespace addition
Josh Elser created HBASE-19040:
--
Summary: CP service exec broken for older clients after PB
namespace addition
Key: HBASE-19040
URL: https://issues.apache.org/jira/browse/HBASE-19040
Project: HBase
Issue Type: Bug
Components: Coprocessors, Protobufs
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Blocker
Fix For: 2.0.0-alpha-4, 1.3.3
Was investigating an upgrade failure at dayjob. The "old" version did not
include HBASE-14077 while the new version did include HBASE-14077.
After the servers have been upgraded, the clients which try to execute CP calls
will begin to fail with a message such as:
{noformat}
$ hbase(main):001:0> user_permission
User
Namespace,Table,Family,Qualifier:Permission
ERROR: org.apache.hadoop.hbase.exceptions.UnknownProtocolException: No
registered coprocessor service found for name AccessControlService in region
hbase:acl,,1508228211139.0ef76894681187f0ef958e78aed64d30.
at
org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7829)
at
org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1980)
at
org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1962)
at
org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32389)
at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2150)
at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
at
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:187)
at
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:167)
{noformat}
The funny part is that the Region actually has a CP registered under the name
{{hbase.pb.AccessControlService}}, but the client asks for one under
{{AccessControlService}}.
I think the easy fix is to deploy the CP under both names while HBase services
support client backwards compatibility with 1.x clients.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19039) remove shadejars clean precommit check
Mike Drob created HBASE-19039: - Summary: remove shadejars clean precommit check Key: HBASE-19039 URL: https://issues.apache.org/jira/browse/HBASE-19039 Project: HBase Issue Type: Bug Components: build Reporter: Mike Drob Assignee: Sean Busbey Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4 per HBASE-18760 ; the shadejars clean check is currently broken due to a typo, we should excise it. needs to be done in all the branches. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19038) precommit mvn install should run from root on patch
Mike Drob created HBASE-19038: - Summary: precommit mvn install should run from root on patch Key: HBASE-19038 URL: https://issues.apache.org/jira/browse/HBASE-19038 Project: HBase Issue Type: Bug Components: build Reporter: Mike Drob Assignee: Mike Drob If the root pom changes we don't properly order the mvn install on the patch and this can lead to problems. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19037) BLOCKCACHE not work in console
Александр created HBASE-19037:
-
Summary: BLOCKCACHE not work in console
Key: HBASE-19037
URL: https://issues.apache.org/jira/browse/HBASE-19037
Project: HBase
Issue Type: Bug
Components: API
Affects Versions: 1.2.6
Reporter: Александр
I'm testing the speed. At the time of the request, I know part of the key.
```
scan 'id_bank', {STARTROW=>"24168557"+"\137",STOPROW=>"24168557"+"\177",COLUMNS
=> ['high', 'low'], BLOCKCACHE => 'true'}
```
When I run the scan, the response returns a short time, and if I make a second
request, the answer is already returned quickly, why?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
Re: Delaying 1.1.13 for another month
Maybe we do a final release on it and then EOL the branch? On Fri, Oct 13, 2017 at 5:25 PM, Nick Dimiduk wrote: > Our beloved branch-1.1 is still showing only the most minor product > changes. Almost everything since 1.1.12 is build, test related. Once again, > I'll let it continue on the back-burner for another month, unless someone > speaks up. > > Same time next month, > -n > > On Mon, Sep 18, 2017 at 9:04 PM, Nick Dimiduk wrote: > > > Heya folks, > > > > There's slim commits to branch-1.1 over the last month. Looks like > nothing > > pressing by my eyes, so I'm going to let the branch simmer for another > > month, let more changes accumulate. Will check back in with you in early > > October. > > > > Reply here if you have strong feeling to the contrary. > > > > Kindly yours, > > Nick > > >
[DISCUSS] Help adding a check for localization edge cases in our current test suites?
Hi folks! This comment from Chia-Ping on HBASE-19020 has me thinking: > The TestXmlParsing is a flaky test in my jenkins, because the error message > from my machine is in Chinese. I wonder how many more of our tests rely incorrectly on the localization settings being set to American English. Would any of our folks who normally work with a locale that isn't American English be willing to help me get a test set up (maybe in our nightly runs?) that tries to catch these kinds of issues?
[jira] [Created] (HBASE-19036) Add action in Chaos Monkey to restart Active Namenode
Monani Mihir created HBASE-19036: Summary: Add action in Chaos Monkey to restart Active Namenode Key: HBASE-19036 URL: https://issues.apache.org/jira/browse/HBASE-19036 Project: HBase Issue Type: Improvement Reporter: Monani Mihir Priority: Minor Under hbase-it we have many actions related to DataNode, Zookeeper, HMaster which gets use with Chaos Monkey and they are useful in testing . Having action which restart Active Namenode would be useful too. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19035) Miss metrics when coprocessor use region scanner to read data
Guanghao Zhang created HBASE-19035: -- Summary: Miss metrics when coprocessor use region scanner to read data Key: HBASE-19035 URL: https://issues.apache.org/jira/browse/HBASE-19035 Project: HBase Issue Type: Bug Reporter: Guanghao Zhang Region interface is exposed to coprocessor. So coprocessor use getScanner to get a region scanner to read data. But the scan metrics was only updated in region server level. So we will miss some scan metrics for the read from coprocessor. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19034) Implement "optimize SEEK to SKIP" in storefile scanner
Guanghao Zhang created HBASE-19034:
--
Summary: Implement "optimize SEEK to SKIP" in storefile scanner
Key: HBASE-19034
URL: https://issues.apache.org/jira/browse/HBASE-19034
Project: HBase
Issue Type: Bug
Reporter: Guanghao Zhang
{code}
protected boolean trySkipToNextRow(Cell cell) throws IOException {
Cell nextCell = null;
do {
Cell nextIndexedKey = getNextIndexedKey();
if (nextIndexedKey != null && nextIndexedKey !=
KeyValueScanner.NO_NEXT_INDEXED_KEY
&& matcher.compareKeyForNextRow(nextIndexedKey, cell) >= 0) {
this.heap.next();
++kvsScanned;
} else {
return false;
}
} while ((nextCell = this.heap.peek()) != null &&
CellUtil.matchingRows(cell, nextCell));
return true;
}
{code}
When SQM return a SEEK_NEXT_ROW, the store scanner will seek to the cell from
next row. HBASE-13109 optimized the SEEK to SKIP when we can read the cell in
current loaded block. So it will skip by call heap.next to the cell from next
row. But the problem is it compare too many times with the nextIndexedKey in
the while loop. We plan move the compare outside the loop to reduce compare
times. One problem is the nextIndexedKey maybe changed when call heap.peek,
because the current storefile scanner was changed. So my proposal is to move
the "optimize SEEK to SKIP" to storefile scanner. When we call seek for
storefile scanner, it may real seek or implement seek by several times skip.
Any suggestions are welcomed. Thanks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
