[jira] [Comment Edited] (HBASE-17958) Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP

[Lars Hofhansl (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-17958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208826#comment-16208826
 ] 

Lars Hofhansl edited comment on HBASE-17958 at 10/18/17 5:40 AM:
-

I can fairly easily eliminate the repeated compare to the next indexed key - 
that does shave off only about 5% of the overall scan time, so not a lot, but 
measurable. I don't think there's any point to check again inside the loop.

The duplicate compares in trySkipToNextRow and trySkipToNextCol are still there 
and the column trackers are still there, though. Those could only be avoided by 
sending the fake cells all the up to the columnTracker, I agree that wasn't 
nice, maybe we can come with other way to eliminate this cost.
HBase is slow in scanning. Perhaps these micro-optimizations aren't worth it.

[~stack]


was (Author: lhofhansl):
I can fairly easily eliminate the repeated compare to the next indexed key - 
that does shave off only about 5% of the overall scan time, so not a lot, but 
measurable. I don't think there's any point to check again inside the loop.

The duplicate compares in trySkipToNextRow and trySkipToNextCol are still there 
and the column trackers are still there, though. Those could only be avoided by 
sending the fake cells all the up to the columnTracker, I agree that wasn't 
nice, maybe we can come with other way to eliminate this cost.
HBase is slow in scanning. Perhaps these micro-optimizations aren't worth it.

> Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP
> 
>
> Key: HBASE-17958
> URL: https://issues.apache.org/jira/browse/HBASE-17958
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: 0001-add-one-ut-testWithColumnCountGetFilter.patch, 
> HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, 
> HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, HBASE-17958-v1.patch, 
> HBASE-17958-v2.patch, HBASE-17958-v3.patch, HBASE-17958-v4.patch, 
> HBASE-17958-v5.patch, HBASE-17958-v6.patch, HBASE-17958-v7.patch, 
> HBASE-17958-v7.patch
>
>
> {code}
> ScanQueryMatcher.MatchCode qcode = matcher.match(cell);
> qcode = optimize(qcode, cell);
> {code}
> The optimize method may change the MatchCode from SEEK_NEXT_COL/SEEK_NEXT_ROW 
> to SKIP. But it still pass the next cell to ScanQueryMatcher. It will get 
> wrong result when use some filter, etc. ColumnCountGetFilter. It just count 
> the  columns's number. If pass a same column to this filter, the count result 
> will be wrong. So we should avoid passing cell to ScanQueryMatcher when 
> optimize SEEK to SKIP.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Chia-Ping Tsai (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208838#comment-16208838
 ] 

Chia-Ping Tsai commented on HBASE-18824:


What I mean is v2 patch need to be updated. greater -> less

> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is 
> MAX_VALUE
> 
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
>  Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch, 
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
>  to correct my wrong understanding. 
> The following documentation says that by default(when the timestamp is not 
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put 
> bq. Doing a put always creates a new version of a cell, at a certain 
> timestamp. {color:#205081}By default the system uses the server’s 
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we 
> want to delete a row. For this you can specify a version, or else 
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code, 
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which 
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side,  timestamp 
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's 
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the 
> new comers steer clear of the confusion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-17958) Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP

[Lars Hofhansl (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-17958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208826#comment-16208826
 ] 

Lars Hofhansl commented on HBASE-17958:
---

I can fairly easily eliminate the repeated compare to the next indexed key - 
that does shave off only about 5% of the overall scan time, so not a lot, but 
measurable. I don't think there's any point to check again inside the loop.

The duplicate compares in trySkipToNextRow and trySkipToNextCol are still there 
and the column trackers are still there, though. Those could only be avoided by 
sending the fake cells all the up to the columnTracker, I agree that wasn't 
nice, maybe we can come with other way to eliminate this cost.
HBase is slow in scanning. Perhaps these micro-optimizations aren't worth it.

> Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP
> 
>
> Key: HBASE-17958
> URL: https://issues.apache.org/jira/browse/HBASE-17958
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: 0001-add-one-ut-testWithColumnCountGetFilter.patch, 
> HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, 
> HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, HBASE-17958-v1.patch, 
> HBASE-17958-v2.patch, HBASE-17958-v3.patch, HBASE-17958-v4.patch, 
> HBASE-17958-v5.patch, HBASE-17958-v6.patch, HBASE-17958-v7.patch, 
> HBASE-17958-v7.patch
>
>
> {code}
> ScanQueryMatcher.MatchCode qcode = matcher.match(cell);
> qcode = optimize(qcode, cell);
> {code}
> The optimize method may change the MatchCode from SEEK_NEXT_COL/SEEK_NEXT_ROW 
> to SKIP. But it still pass the next cell to ScanQueryMatcher. It will get 
> wrong result when use some filter, etc. ColumnCountGetFilter. It just count 
> the  columns's number. If pass a same column to this filter, the count result 
> will be wrong. So we should avoid passing cell to ScanQueryMatcher when 
> optimize SEEK to SKIP.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208810#comment-16208810
 ] 

stack edited comment on HBASE-12260 at 10/18/17 5:07 AM:
-

Resolving as "won't fix".

The direction I was taking here, and the direction on the RegionServer side 
done in HBASE-18183, has been superceded by a superior approach up in 
HBASE-19007, Align Services Interfaces in Master and RegionServer (HBASE_18183 
was committed, HBASE-19007 changes it).

In here, we took a pure approach than that pursued in HBASE-18183. In here, we 
gave MasterServices and Services a pruning shearing all of the IA.Private 
classes to make MS and S for for Coprocessor consumption (All exposed classes 
were InterfaceAudience.LimitedPrivate or Public, no IA.Private classes 
exposed). Internally, we then did a bunch of code refactoring to make it so 
Tests, Managers, and Services, rather than use MasterServices, instead used 
HMaster explicitly everywhere; i.e. use the actual implementation rather than 
an Interface.

HBASE_18183 did somewhat similar but left over a special 
CoprocessorRegionServerServices, yet-another-interface, that was to give CPs a 
subset of RegionServerServices.

HBASE-19007 was about unifying the approaches but we were hung up on how to 
expose Server or some set of MasterServices or RegionServerServices to CPs. It 
was also a bummer having to give MS and RSS over to the CP audience with all of 
its constraints giving up on the original intent of MS and RSS being a subset 
of HMaster or HRegionServer so we could mock, inject, etc. (See the dev list 
discussion on MS and RSS having two different clients with two different 
demands).  Discussion up on HBASE-19007 came up with a superior approach, not 
exposing Server or Master/RegionServerServices to Coprocessors at all.


was (Author: stack):
Resolving as "won't fix".

The direction I was taking here, and the direction on the RegionServer side 
done in HBASE-18183, has been superceded by a superior approach up in 
HBASE-19007, Align Services Interfaces in Master and RegionServer (HBASE_18183 
was committed, HBASE-19007 changes it).

In here, we took a pure approach than that pursued in HBASE-18183. In here, we 
gave MasterServices and Services a pruning shearing all of the IA.Private 
classes to make MS and S for for Coprocessor consumption (All exposed classes 
were InterfaceAudience.LimitedPrivate or Public, no IA.Private classes 
exposed). Internally, we then did a bunch of code refactoring to make it so 
Tests, Managers, and Services, rather than use MasterServices, instead used 
HMaster explicitly everywhere; i.e. use the actual implementation rather than 
an Interface.

HBASE_18183 did somewhat similar but left over a special 
CoprocessorRegionServerServices, yet-another-interface, that was to give CPs a 
subset of RegionServerServices.

HBASE-19007 was about unifying the approaches but we were hung up on how to 
expose Server or some set of MasterServices or RegionServerServices to CPs. 
Discussion up on HBASE-19007 came up with a superior approach, not exposing 
Server or Master/RegionServerServices to Coprocessors at all.

> MasterServices needs a short-back-and-sides; pare-back exposure of internals 
> and IA.Private classes
> ---
>
> Key: HBASE-12260
> URL: https://issues.apache.org/jira/browse/HBASE-12260
> Project: HBase
>  Issue Type: Sub-task
>  Components: master
>Reporter: ryan rawson
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-12260.master.001.patch, 
> HBASE-12260.master.002.patch, HBASE-12260.master.003.patch, 
> HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, 
> HBASE-12260.master.006.patch, HBASE-12260.master.007.patch, 
> HBASE-12260.master.008.patch, HBASE-12260.master.009.patch, 
> HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, 
> HBASE-12260.master.011.patch, HBASE-12260.master.012.patch, 
> HBASE-12260.master.013.patch, HBASE-12260.master.014.patch
>
>
> A major issue with MasterServices is the MasterCoprocessorEnvironment exposes 
> this class even though MasterServices is tagged with 
> @InterfaceAudience.Private
> This means that the entire internals of the HMaster is essentially part of 
> the coprocessor API.  Many of the classes returned by the MasterServices API 
> are highly internal, extremely powerful, and subject to constant change.  
> Perhaps a new API to replace MasterServices that is use-case focused, and 
> justified based on real world co-processors would suit things better.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208810#comment-16208810
 ] 

stack edited comment on HBASE-12260 at 10/18/17 5:02 AM:
-

Resolving as "won't fix".

The direction I was taking here, and the direction on the RegionServer side 
done in HBASE-18183, has been superceded by a superior approach up in 
HBASE-19007, Align Services Interfaces in Master and RegionServer (HBASE_18183 
was committed, HBASE-19007 changes it).

In here, we took a pure approach than that pursued in HBASE-18183. In here, we 
gave MasterServices and Services a pruning shearing all of the IA.Private 
classes to make MS and S for for Coprocessor consumption (All exposed classes 
were InterfaceAudience.LimitedPrivate or Public, no IA.Private classes 
exposed). Internally, we then did a bunch of code refactoring to make it so 
Tests, Managers, and Services, rather than use MasterServices, instead used 
HMaster explicitly everywhere; i.e. use the actual implementation rather than 
an Interface.

HBASE_18183 did somewhat similar but left over a special 
CoprocessorRegionServerServices, yet-another-interface, that was to give CPs a 
subset of RegionServerServices.

HBASE-19007 was about unifying the approaches but we were hung up on how to 
expose Server or some set of MasterServices or RegionServerServices to CPs. 
Discussion up on HBASE-19007 came up with a superior approach, not exposing 
Server or Master/RegionServerServices to Coprocessors at all.


was (Author: stack):
Resolving as "won't fix".

The direction I was taking here, and the direction on the RegionServer side 
done in HBASE-18183, has been superceded by a superior approach up in 
HBASE-19007.

In here, we took a more pure approach than that pursued in HBASE-18183. In 
here, we gave MasterServices and Services a pruning shearing all of the 
IA.Private classes to make MS and S for for Coprocessor consumption (All 
exposed classes were InterfaceAudience.LimitedPrivate or Public, no IA.Private 
classes exposed). Internally, we then did a bunch of code refactoring to make 
it so Tests, Managers, and Services, rather than use MasterServices, instead 
used HMaster explicitly everywhere; i.e. use the actual implementation rather 
than an Interface.

> MasterServices needs a short-back-and-sides; pare-back exposure of internals 
> and IA.Private classes
> ---
>
> Key: HBASE-12260
> URL: https://issues.apache.org/jira/browse/HBASE-12260
> Project: HBase
>  Issue Type: Sub-task
>  Components: master
>Reporter: ryan rawson
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-12260.master.001.patch, 
> HBASE-12260.master.002.patch, HBASE-12260.master.003.patch, 
> HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, 
> HBASE-12260.master.006.patch, HBASE-12260.master.007.patch, 
> HBASE-12260.master.008.patch, HBASE-12260.master.009.patch, 
> HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, 
> HBASE-12260.master.011.patch, HBASE-12260.master.012.patch, 
> HBASE-12260.master.013.patch, HBASE-12260.master.014.patch
>
>
> A major issue with MasterServices is the MasterCoprocessorEnvironment exposes 
> this class even though MasterServices is tagged with 
> @InterfaceAudience.Private
> This means that the entire internals of the HMaster is essentially part of 
> the coprocessor API.  Many of the classes returned by the MasterServices API 
> are highly internal, extremely powerful, and subject to constant change.  
> Perhaps a new API to replace MasterServices that is use-case focused, and 
> justified based on real world co-processors would suit things better.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208815#comment-16208815
 ] 

Hudson commented on HBASE-19032:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3907 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/3907/])
HBASE-19032 Set mimetype for patches uploaded by submit-patch.py (appy: rev 
5368fd5bf0a281e67c4dde25816a1362d1f0a3f0)
* (edit) dev-support/submit-patch.py


> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19014) surefire fails; When writing xml report stdout/stderr ... No such file or directory

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208813#comment-16208813
 ] 

Hadoop QA commented on HBASE-19014:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
22s{color} | {color:blue} Docker mode activated. {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:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  7m 
14s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
17s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
14s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
54s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 12m 
46s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  1m 
44s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  2m 
20s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  1m 
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
13s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
16s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green}  0m 
37s{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} xml {color} | {color:green}  0m  
0s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  2m 
 3s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
23m 33s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3. 
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  1m 
40s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  2m 
24s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}988m 39s{color} 
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
25s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}1039m  3s{color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f1cc2c |
| JIRA Issue | HBASE-19014 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12892583/HBASE-19014.branch-1.v0.patch
 |
| Optional Tests |  asflicense  shadedjars  javac  javadoc  unit  xml  compile  
|
| uname | Linux 7439a41fccc4 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12 
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | branch-1 / aeffd3a |
| Default Java | 1.7.0_151 |
| Multi-JDK versions |  /usr/lib/jvm/java-8-oracle:1.8.0_144 

[jira] [Updated] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-12260:
--
Resolution: Won't Fix
Status: Resolved  (was: Patch Available)

Resolving as "won't fix".

The direction I was taking here, and the direction on the RegionServer side 
done in HBASE-18183, has been superceded by a superior approach up in 
HBASE-19007.

In here, we took a more pure approach than that pursued in HBASE-18183. In 
here, we gave MasterServices and Services a pruning shearing all of the 
IA.Private classes to make MS and S for for Coprocessor consumption (All 
exposed classes were InterfaceAudience.LimitedPrivate or Public, no IA.Private 
classes exposed). Internally, we then did a bunch of code refactoring to make 
it so Tests, Managers, and Services, rather than use MasterServices, instead 
used HMaster explicitly everywhere; i.e. use the actual implementation rather 
than an Interface.

> MasterServices needs a short-back-and-sides; pare-back exposure of internals 
> and IA.Private classes
> ---
>
> Key: HBASE-12260
> URL: https://issues.apache.org/jira/browse/HBASE-12260
> Project: HBase
>  Issue Type: Sub-task
>  Components: master
>Reporter: ryan rawson
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-12260.master.001.patch, 
> HBASE-12260.master.002.patch, HBASE-12260.master.003.patch, 
> HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, 
> HBASE-12260.master.006.patch, HBASE-12260.master.007.patch, 
> HBASE-12260.master.008.patch, HBASE-12260.master.009.patch, 
> HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, 
> HBASE-12260.master.011.patch, HBASE-12260.master.012.patch, 
> HBASE-12260.master.013.patch, HBASE-12260.master.014.patch
>
>
> A major issue with MasterServices is the MasterCoprocessorEnvironment exposes 
> this class even though MasterServices is tagged with 
> @InterfaceAudience.Private
> This means that the entire internals of the HMaster is essentially part of 
> the coprocessor API.  Many of the classes returned by the MasterServices API 
> are highly internal, extremely powerful, and subject to constant change.  
> Perhaps a new API to replace MasterServices that is use-case focused, and 
> justified based on real world co-processors would suit things better.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-17958) Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP

[Lars Hofhansl (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-17958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208801#comment-16208801
 ] 

Lars Hofhansl edited comment on HBASE-17958 at 10/18/17 4:41 AM:
-

So I just ran a things through a profiler for some unrelated stuff and now find 
that a whopping *third* of the time for the scan I am doing is spent in 
{{trySkipToNextRow}}. That is not quite what I had intended with my original 
idea. :)

Looking into that function (in branch-1) I see that each time we SKIP 
(heap.next()) we re-check the next indexed key.

It's entirely possible that I am missing something... But it seems to me we 
should check for SEEK outside of the loop once, then either return false, or 
unconditionally continue SKIP'ing along.

[~Apache9], [~zghaobac].


was (Author: lhofhansl):
So I just ran a things through a profiler for some unrelated stuff and now find 
that a whopping *third* of the time for the scan I am doing is spent in 
{{trySkipToNextRow}}. That is certainly what I had intended with my original 
idea.

Looking into that function (in branch-1) I see that each time we SKIP 
(heap.next()) we re-check the next indexed key.

It's entirely possible that I am missing something... But it seems to me we 
should check for SEEK outside of the loop once, then either return false, or 
unconditionally continue SKIP'ing along.

[~Apache9], [~zghaobac].

> Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP
> 
>
> Key: HBASE-17958
> URL: https://issues.apache.org/jira/browse/HBASE-17958
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: 0001-add-one-ut-testWithColumnCountGetFilter.patch, 
> HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, 
> HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, HBASE-17958-v1.patch, 
> HBASE-17958-v2.patch, HBASE-17958-v3.patch, HBASE-17958-v4.patch, 
> HBASE-17958-v5.patch, HBASE-17958-v6.patch, HBASE-17958-v7.patch, 
> HBASE-17958-v7.patch
>
>
> {code}
> ScanQueryMatcher.MatchCode qcode = matcher.match(cell);
> qcode = optimize(qcode, cell);
> {code}
> The optimize method may change the MatchCode from SEEK_NEXT_COL/SEEK_NEXT_ROW 
> to SKIP. But it still pass the next cell to ScanQueryMatcher. It will get 
> wrong result when use some filter, etc. ColumnCountGetFilter. It just count 
> the  columns's number. If pass a same column to this filter, the count result 
> will be wrong. So we should avoid passing cell to ScanQueryMatcher when 
> optimize SEEK to SKIP.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-17958) Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP

[Lars Hofhansl (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-17958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208801#comment-16208801
 ] 

Lars Hofhansl edited comment on HBASE-17958 at 10/18/17 4:40 AM:
-

So I just ran a things through a profiler for some unrelated stuff and now find 
that a whopping *third* of the scan I am doing is spent in 
{{trySkipToNextRow}}. That is certainly what I had intended with my original 
idea.

Looking into that function (in branch-1) I see that each time we SKIP 
(heap.next()) we re-check the next indexed key.

It's entirely possible that I am missing something... But it seems to me we 
should check for SEEK outside of the loop once, then either return false, or 
unconditionally continue SKIP'ing along.

[~Apache9], [~zghaobac].


was (Author: lhofhansl):
So I just ran a things through a profiler for some unrelated stuff and now find 
that a whopping *third* of the scan I am doing is spent in 
{{trySkipToNextRow}}. That is certainly what I had intended with my original 
idea.

Looking into that function (in branch-1) I see that each time we SKIP 
(heap.next()) we re-check the next indexed key.

It's entirely possible that I am missing something... But it seems to me we 
should check for SEEK outside of the loop once, then either return false, or 
unconditionally continue SKIP'ing along.


> Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP
> 
>
> Key: HBASE-17958
> URL: https://issues.apache.org/jira/browse/HBASE-17958
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: 0001-add-one-ut-testWithColumnCountGetFilter.patch, 
> HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, 
> HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, HBASE-17958-v1.patch, 
> HBASE-17958-v2.patch, HBASE-17958-v3.patch, HBASE-17958-v4.patch, 
> HBASE-17958-v5.patch, HBASE-17958-v6.patch, HBASE-17958-v7.patch, 
> HBASE-17958-v7.patch
>
>
> {code}
> ScanQueryMatcher.MatchCode qcode = matcher.match(cell);
> qcode = optimize(qcode, cell);
> {code}
> The optimize method may change the MatchCode from SEEK_NEXT_COL/SEEK_NEXT_ROW 
> to SKIP. But it still pass the next cell to ScanQueryMatcher. It will get 
> wrong result when use some filter, etc. ColumnCountGetFilter. It just count 
> the  columns's number. If pass a same column to this filter, the count result 
> will be wrong. So we should avoid passing cell to ScanQueryMatcher when 
> optimize SEEK to SKIP.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-17958) Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP

[Lars Hofhansl (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-17958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208801#comment-16208801
 ] 

Lars Hofhansl edited comment on HBASE-17958 at 10/18/17 4:40 AM:
-

So I just ran a things through a profiler for some unrelated stuff and now find 
that a whopping *third* of the time for the scan I am doing is spent in 
{{trySkipToNextRow}}. That is certainly what I had intended with my original 
idea.

Looking into that function (in branch-1) I see that each time we SKIP 
(heap.next()) we re-check the next indexed key.

It's entirely possible that I am missing something... But it seems to me we 
should check for SEEK outside of the loop once, then either return false, or 
unconditionally continue SKIP'ing along.

[~Apache9], [~zghaobac].


was (Author: lhofhansl):
So I just ran a things through a profiler for some unrelated stuff and now find 
that a whopping *third* of the scan I am doing is spent in 
{{trySkipToNextRow}}. That is certainly what I had intended with my original 
idea.

Looking into that function (in branch-1) I see that each time we SKIP 
(heap.next()) we re-check the next indexed key.

It's entirely possible that I am missing something... But it seems to me we 
should check for SEEK outside of the loop once, then either return false, or 
unconditionally continue SKIP'ing along.

[~Apache9], [~zghaobac].

> Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP
> 
>
> Key: HBASE-17958
> URL: https://issues.apache.org/jira/browse/HBASE-17958
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: 0001-add-one-ut-testWithColumnCountGetFilter.patch, 
> HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, 
> HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, HBASE-17958-v1.patch, 
> HBASE-17958-v2.patch, HBASE-17958-v3.patch, HBASE-17958-v4.patch, 
> HBASE-17958-v5.patch, HBASE-17958-v6.patch, HBASE-17958-v7.patch, 
> HBASE-17958-v7.patch
>
>
> {code}
> ScanQueryMatcher.MatchCode qcode = matcher.match(cell);
> qcode = optimize(qcode, cell);
> {code}
> The optimize method may change the MatchCode from SEEK_NEXT_COL/SEEK_NEXT_ROW 
> to SKIP. But it still pass the next cell to ScanQueryMatcher. It will get 
> wrong result when use some filter, etc. ColumnCountGetFilter. It just count 
> the  columns's number. If pass a same column to this filter, the count result 
> will be wrong. So we should avoid passing cell to ScanQueryMatcher when 
> optimize SEEK to SKIP.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-17958) Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP

[Lars Hofhansl (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-17958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208801#comment-16208801
 ] 

Lars Hofhansl commented on HBASE-17958:
---

So I just ran a things through a profiler for some unrelated stuff and now find 
that a whopping *third* of the scan I am doing is spent in 
{{trySkipToNextRow}}. That is certainly what I had intended with my original 
idea.

Looking into that function (in branch-1) I see that each time we SKIP 
(heap.next()) we re-check the next indexed key.

It's entirely possible that I am missing something... But it seems to me we 
should check for SEEK outside of the loop once, then either return false, or 
unconditionally continue SKIP'ing along.


> Avoid passing unexpected cell to ScanQueryMatcher when optimize SEEK to SKIP
> 
>
> Key: HBASE-17958
> URL: https://issues.apache.org/jira/browse/HBASE-17958
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: 0001-add-one-ut-testWithColumnCountGetFilter.patch, 
> HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, 
> HBASE-17958-branch-1.patch, HBASE-17958-branch-1.patch, HBASE-17958-v1.patch, 
> HBASE-17958-v2.patch, HBASE-17958-v3.patch, HBASE-17958-v4.patch, 
> HBASE-17958-v5.patch, HBASE-17958-v6.patch, HBASE-17958-v7.patch, 
> HBASE-17958-v7.patch
>
>
> {code}
> ScanQueryMatcher.MatchCode qcode = matcher.match(cell);
> qcode = optimize(qcode, cell);
> {code}
> The optimize method may change the MatchCode from SEEK_NEXT_COL/SEEK_NEXT_ROW 
> to SKIP. But it still pass the next cell to ScanQueryMatcher. It will get 
> wrong result when use some filter, etc. ColumnCountGetFilter. It just count 
> the  columns's number. If pass a same column to this filter, the count result 
> will be wrong. So we should avoid passing cell to ScanQueryMatcher when 
> optimize SEEK to SKIP.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-13346) Clean up Filter package for post 1.0 s/KeyValue/Cell/g

[Anoop Sam John (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208798#comment-16208798
 ] 

Anoop Sam John commented on HBASE-13346:


Patch V8 LGTM.   
FilterWrapper also non exposed private class.  Same thing did for ACL filter 
etc is enough for this too!..   Not sure why we added this wrapper in client 
module . It can be in server module.  Can we move that also as part of this 
patch?  Any concerns from others working in Filter cleanup/fix area?

> Clean up Filter package for post 1.0 s/KeyValue/Cell/g
> --
>
> Key: HBASE-13346
> URL: https://issues.apache.org/jira/browse/HBASE-13346
> Project: HBase
>  Issue Type: Bug
>  Components: API, Filters
>Affects Versions: 2.0.0
>Reporter: Lars George
>Assignee: Tamas Penzes
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-13346.master.001.patch, 
> HBASE-13346.master.002.patch, HBASE-13346.master.003.patch, 
> HBASE-13346.master.003.patch, HBASE-13346.master.004.patch, 
> HBASE-13346.master.005.patch, HBASE-13346.master.006.patch, 
> HBASE-13346.master.007.patch, HBASE-13346.master.008.patch
>
>
> Since we have a bit of a messy Filter API with KeyValue vs Cell reference 
> mixed up all over the place, I recommend cleaning this up once and for all. 
> There should be no {{KeyValue}} (or {{kv}}, {{kvs}} etc.) in any method or 
> parameter name.
> This includes deprecating and renaming filters too, for example 
> {{FirstKeyOnlyFilter}}, which really should be named {{FirstKeyValueFilter}} 
> as it does _not_ just return the key, but the entire cell. It should be 
> deprecated and renamed to {{FirstCellFilter}} (or {{FirstColumnFilter}} if 
> you prefer).
> In general we should clarify and settle on {{KeyValue}} vs {{Cell}} vs 
> {{Column}} in our naming. The latter two are the only ones going forward with 
> the public API, and are used synonymous. We should carefully check which is 
> better suited (is it really a specific cell, or the newest cell, aka the 
> newest column value) and settle on a naming schema.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18906) Investigate Phoenix usages of Region#waitForXXX APIs

[Anoop Sam John (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208792#comment-16208792
 ] 

Anoop Sam John commented on HBASE-18906:


Just trying to understand more that is why may be more Qs I raised.
One thing pls note that in Region or Store, we are not giving blocking call 
APIs now..  Those for flush/compaction are been replaced by requestXXX..  Ya 
may be some are still missing but will add.. Also for Compaction, Duo is 
working on the Tracker interface with which the callee can track the progress.  
 That is why my point was against a waitForXXX API..   Also that does not say 
wait for which particular flush/compaction process..   The system may have just 
finished the flush/compaction but that does not mean when the CP code is 
executing no flush/compaction is happening.   Seeing the code in Phoenix , I 
believe a flush finish notify can help there so avoid this sleep for some time. 
 The listener can notify the waiting CP code (commitBatch). 

> Investigate Phoenix usages of Region#waitForXXX APIs
> 
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19007) Align Services Interfaces in Master and RegionServer

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208790#comment-16208790
 ] 

stack commented on HBASE-19007:
---

.004 cleanup.Lets see how it does against hadoopqa. Below is commit comment. 
Feedback?

{code}
HBASE-19007 Align Services Interfaces in Master and RegionServer

Purges Server, MasterServices, and RegionServerServices from
CoprocessorEnvironments. Replaces removed functionality with
a set of carefully curated methods on the *CoprocessorEnvironment
implementations (Varies by CoprocessorEnvironment in that the
MasterCoprocessorEnvironment has Master-type facility exposed,
and so on).

A few core Coprocessors that should long ago have been converted
to be integral, violate their context; e.g. a RegionCoprocessor
wants free access to a hosting RegionServer (which may or may not
be present). Rather than let these violators make us corrupte the
CP API, instead, we've made up a hacky system that allows core
Coprocessors access to internals. A new CoreCoprocessor Annotation
has been introduced. When loading Coprocessors, if the instance is
annotated CoreCoprocessor, we pass it an Environment that has been
padded w/ extra-stuff. On invocation, CoreCoprocessors know how to
route their way to these extras in their environment.

See the *CoprocessoHost for how the do the check for CoreCoprocessor
and pass a fatter *Coprocessor, one that allows getting of either
a RegionServerService or MasterService out of the environment
via Marker Interfaces.

Removed org.apache.hadoop.hbase.regionserver.CoprocessorRegionServerServices

M 
hbase-endpoint/src/main/java/org/apache/hadoop/hbase/security/access/SecureBulkLoadEndpoint.java
 This Endpoint has been deprecated because its functionality has been
 moved to core. Marking it a CoreCoprocessor in the meantime to
 minimize change.

M 
hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupAdminEndpoint.java
 This should be integral to hbase. Meantime, marking it CoreCoprocessor.

M hbase-server/src/main/java/org/apache/hadoop/hbase/Server.java
 Added doc on where it is used and added back a few methods we'd
removed.

A 
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoreCoprocessor.java
 New annotation for core hbase coprocessors. They get richer environment
 on coprocessor loading.

A 
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/HasMasterServices.java
A 
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/HasRegionServerServices.java
 Marker Interface to access extras if present.

M 
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/MasterCoprocessorEnvironment.java
  Purge MasterServices access. Allow CPs a Connection.

M 
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/RegionCoprocessorEnvironment.java
  Purge RegionServerServices access. Allow CPs a Connection.

M 
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/RegionServerCoprocessorEnvironment.java
  Purge MasterServices access. Allow CPs a Connection.

M 
hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/MasterSpaceQuotaObserver.java
M hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/QuotaCache.java
  We no longer have access to MasterServices. Don't need it actually.
  Use short-circuiting Admin instead.

D 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CoprocessorRegionServerServices.java
  Removed. Not needed now we do CP Env differently.

M 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
  No need to go via RSS to getOnlineTables; just use HRS.

And so on. Adds tests to ensure we can only get at extra info
if the CP has been properly marked.
{code}

> Align Services Interfaces in Master and RegionServer
> 
>
> Key: HBASE-19007
> URL: https://issues.apache.org/jira/browse/HBASE-19007
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Priority: Blocker
> Attachments: HBASE-19007.master.001.patch, 
> HBASE-19007.master.002.patch, HBASE-19007.master.003.patch, 
> HBASE-19007.master.004.patch
>
>
> HBASE-18183 adds a CoprocessorRegionServerService to give a view on 
> RegionServiceServices that is safe to expose to Coprocessors.
> On the Master-side, MasterServices becomes an Interface for exposing to 
> Coprocessors.
> We need to align the two.
> For background, see 
> https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820
>  



--
This message was sent by Atlassian JIRA

[jira] [Updated] (HBASE-19007) Align Services Interfaces in Master and RegionServer

[stack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-19007:
--
Attachment: HBASE-19007.master.004.patch

> Align Services Interfaces in Master and RegionServer
> 
>
> Key: HBASE-19007
> URL: https://issues.apache.org/jira/browse/HBASE-19007
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Priority: Blocker
> Attachments: HBASE-19007.master.001.patch, 
> HBASE-19007.master.002.patch, HBASE-19007.master.003.patch, 
> HBASE-19007.master.004.patch
>
>
> HBASE-18183 adds a CoprocessorRegionServerService to give a view on 
> RegionServiceServices that is safe to expose to Coprocessors.
> On the Master-side, MasterServices becomes an Interface for exposing to 
> Coprocessors.
> We need to align the two.
> For background, see 
> https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Xiang Li (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208782#comment-16208782
 ] 

Xiang Li commented on HBASE-18824:
--

[~chia7712], any comment to patch 002? 8-)

> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is 
> MAX_VALUE
> 
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
>  Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch, 
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
>  to correct my wrong understanding. 
> The following documentation says that by default(when the timestamp is not 
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put 
> bq. Doing a put always creates a new version of a cell, at a certain 
> timestamp. {color:#205081}By default the system uses the server’s 
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we 
> want to delete a row. For this you can specify a version, or else 
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code, 
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which 
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side,  timestamp 
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's 
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the 
> new comers steer clear of the confusion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE

[Xiang Li (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208781#comment-16208781
 ] 

Xiang Li commented on HBASE-18824:
--

Yes, I believe the reason why {{result.size() > count}} is an exception which 
should not happen is the max version of Get is set to count 
{code:title=HRegion.java|borderStyle=solid}
public void prepareDeleteTimestamps(Mutation mutation, Map 
familyMap,
  byte[] byteNow) throws IOException {
  //...
  Get get = new Get(CellUtil.cloneRow(cell));
  get.setMaxVersions(count); <-- here
  get.addColumn(family, qual);
  if (coprocessorHost != null) {
if (!coprocessorHost.prePrepareTimeStampForDeleteVersion(mutation, 
cell,
byteNow, get)) {
  updateDeleteLatestVersionTimeStamp(cell, get, count, byteNow);
}
  } else {
updateDeleteLatestVersionTimeStamp(cell, get, count, byteNow);
  }
}
{code}

> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is 
> MAX_VALUE
> 
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
>  Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch, 
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's 
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
>  to correct my wrong understanding. 
> The following documentation says that by default(when the timestamp is not 
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put 
> bq. Doing a put always creates a new version of a cell, at a certain 
> timestamp. {color:#205081}By default the system uses the server’s 
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we 
> want to delete a row. For this you can specify a version, or else 
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code, 
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which 
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side,  timestamp 
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's 
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the 
> new comers steer clear of the confusion.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (HBASE-18945) Make a IA.LimitedPrivate interface for CellComparator

[Ted Yu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu resolved HBASE-18945.

Resolution: Fixed

> Make a IA.LimitedPrivate interface for CellComparator
> -
>
> Key: HBASE-18945
> URL: https://issues.apache.org/jira/browse/HBASE-18945
> Project: HBase
>  Issue Type: Sub-task
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0-alpha-4
>
> Attachments: 18945-addendum-branch-2.txt, HBASE-18495.patch, 
> HBASE-18945_2.patch, HBASE-18945_3.patch, HBASE-18945_4.patch, 
> HBASE-18945_5.patch, HBASE-18945_6.patch, HBASE-18945_6.patch, 
> HBASE-18945_7.patch
>
>
> Based on discussions over in HBASE-18826 and HBASE-18183 it is better we 
> expose CellComparator as a public interface so that it could be used in 
> Region/Store interfaces to be exposed to CPs.
> Currently the Comparator is exposed in Region, STore and StoreFile. There is 
> another discussion whether to expose it at all layers or only at Region. 
> However since we are exposing this to CPs CellComparator being @Private is 
> not the ideal way to do it. We have to change it to LimitedPrivate. But 
> CellComparator has lot of additional methods which are internal (like where a 
> Cell is compared with an incoming byte[] used in index comparsions etc).
> One way to expose is that as being done now in HBASE-18826 - by exposing the 
> return type as Comparator. But this is not powerful. It only allows to 
> compare cells. So we try to expose an IA.LimitedPrivate interface that is 
> more powerful and allows comparing individual cell components also. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208770#comment-16208770
 ] 

Hudson commented on HBASE-19032:


FAILURE: Integrated in Jenkins build HBase-2.0 #706 (See 
[https://builds.apache.org/job/HBase-2.0/706/])
HBASE-19032 Set mimetype for patches uploaded by submit-patch.py (appy: rev 
16ccd55c43a114353fbb04c707d4cf3fa8b711f2)
* (edit) dev-support/submit-patch.py


> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18945) Make a IA.LimitedPrivate interface for CellComparator

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208771#comment-16208771
 ] 

Hudson commented on HBASE-18945:


FAILURE: Integrated in Jenkins build HBase-2.0 #706 (See 
[https://builds.apache.org/job/HBase-2.0/706/])
HBASE-18945 Make a IA.LimitedPrivate interface for CellComparator - (tedyu: rev 
998bc32ec9bd89d61a0d918b2955f84772492f03)
* (edit) 
hbase-mapreduce/src/main/java/org/apache/hadoop/hbase/mapreduce/KeyValueSortReducer.java
* (edit) 
hbase-mapreduce/src/main/java/org/apache/hadoop/hbase/mapreduce/Import.java


> Make a IA.LimitedPrivate interface for CellComparator
> -
>
> Key: HBASE-18945
> URL: https://issues.apache.org/jira/browse/HBASE-18945
> Project: HBase
>  Issue Type: Sub-task
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0-alpha-4
>
> Attachments: 18945-addendum-branch-2.txt, HBASE-18495.patch, 
> HBASE-18945_2.patch, HBASE-18945_3.patch, HBASE-18945_4.patch, 
> HBASE-18945_5.patch, HBASE-18945_6.patch, HBASE-18945_6.patch, 
> HBASE-18945_7.patch
>
>
> Based on discussions over in HBASE-18826 and HBASE-18183 it is better we 
> expose CellComparator as a public interface so that it could be used in 
> Region/Store interfaces to be exposed to CPs.
> Currently the Comparator is exposed in Region, STore and StoreFile. There is 
> another discussion whether to expose it at all layers or only at Region. 
> However since we are exposing this to CPs CellComparator being @Private is 
> not the ideal way to do it. We have to change it to LimitedPrivate. But 
> CellComparator has lot of additional methods which are internal (like where a 
> Cell is compared with an incoming byte[] used in index comparsions etc).
> One way to expose is that as being done now in HBASE-18826 - by exposing the 
> return type as Comparator. But this is not powerful. It only allows to 
> compare cells. So we try to expose an IA.LimitedPrivate interface that is 
> more powerful and allows comparing individual cell components also. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19001) Remove the hooks in RegionObserver which are designed to construct a StoreScanner which is marked as IA.Private

[Duo Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang updated HBASE-19001:
--
  Resolution: Fixed
Hadoop Flags: Incompatible change,Reviewed  (was: Incompatible change)
  Status: Resolved  (was: Patch Available)

Pushed to master and branch-2.

Thanks all for reviewing. Let me start working on the follow-on issues.

> Remove the hooks in RegionObserver which are designed to construct a 
> StoreScanner which is marked as IA.Private
> ---
>
> Key: HBASE-19001
> URL: https://issues.apache.org/jira/browse/HBASE-19001
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19001-v1.patch, HBASE-19001-v2.patch, 
> HBASE-19001.patch
>
>
> There are three methods here
> {code}
> KeyValueScanner 
> preStoreScannerOpen(ObserverContext c,
>   Store store, Scan scan, NavigableSet targetCols, 
> KeyValueScanner s, long readPt)
>   throws IOException;
> InternalScanner 
> preFlushScannerOpen(ObserverContext c,
>   Store store, List scanners, InternalScanner s, long 
> readPoint)
>   throws IOException;
> InternalScanner 
> preCompactScannerOpen(ObserverContext c,
>   Store store, List scanners, ScanType 
> scanType, long earliestPutTs,
>   InternalScanner s, CompactionLifeCycleTracker tracker, 
> CompactionRequest request,
>   long readPoint) throws IOException;
> {code}
> For the flush and compact ones, we've discussed many times, it is not safe to 
> let user inject a Filter or even implement their own InternalScanner using 
> the store file scanners, as our correctness highly depends on the complicated 
> logic in SQM and StoreScanner. CP users are expected to wrap the original 
> InternalScanner(it is a StoreScanner anyway) in preFlush/preCompact methods 
> to do filtering or something else.
> For preStoreScannerOpen it even returns a KeyValueScanner which is marked as 
> IA.Private... This is less hurt but still, we've decided to not expose 
> StoreScanner to CP users so here this method is useless. CP users can use 
> preGetOp and preScannerOpen method to modify the Get/Scan object passed in to 
> inject into the scan operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-15071) Cleanup bypass semantic in MasterCoprocessorHost

[Duo Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208760#comment-16208760
 ] 

Duo Zhang commented on HBASE-15071:
---

Got it sir.

> Cleanup bypass semantic in MasterCoprocessorHost
> 
>
> Key: HBASE-15071
> URL: https://issues.apache.org/jira/browse/HBASE-15071
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Umesh Agashe
>Priority: Blocker
> Attachments: HBASE-15071.patch
>
>
> Lets decide on this one before we release 2.0.0.
> A bunch of methods in MasterCoprocessorHost on the 'pre' step allow returning 
> true which indicates the method invocation is not to proceed.
> Not all 'pre' steps do this. Just some.
> Seems a little arbitrary.
> How we skip out if we are not proceed with the invocation is also a little 
> arbitrary.
> When a deleteColumn call is supposed to skip out, it returns a -1, a 
> non-procId. If we are to skip a balance call, we log that CP said skip and 
> then return false to indicate the balancer did not run (why?). Elsewhere we 
> just exit silently. In createNamespace we used to exit silently but 
> HBASE-14888 just changed it so we throw a BypassCoprocessorException 
> instead... 
> Lets make them all work the same way.
> (This issue comes of chat w/ Matteo)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-15071) Cleanup bypass semantic in MasterCoprocessorHost

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208755#comment-16208755
 ] 

stack commented on HBASE-15071:
---

[~Apache9] I was going to have a go after HBASE-19007 sir.

> Cleanup bypass semantic in MasterCoprocessorHost
> 
>
> Key: HBASE-15071
> URL: https://issues.apache.org/jira/browse/HBASE-15071
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Umesh Agashe
>Priority: Blocker
> Attachments: HBASE-15071.patch
>
>
> Lets decide on this one before we release 2.0.0.
> A bunch of methods in MasterCoprocessorHost on the 'pre' step allow returning 
> true which indicates the method invocation is not to proceed.
> Not all 'pre' steps do this. Just some.
> Seems a little arbitrary.
> How we skip out if we are not proceed with the invocation is also a little 
> arbitrary.
> When a deleteColumn call is supposed to skip out, it returns a -1, a 
> non-procId. If we are to skip a balance call, we log that CP said skip and 
> then return false to indicate the balancer did not run (why?). Elsewhere we 
> just exit silently. In createNamespace we used to exit silently but 
> HBASE-14888 just changed it so we throw a BypassCoprocessorException 
> instead... 
> Lets make them all work the same way.
> (This issue comes of chat w/ Matteo)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-15071) Cleanup bypass semantic in MasterCoprocessorHost

[Duo Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208747#comment-16208747
 ] 

Duo Zhang commented on HBASE-15071:
---

Any progress here? After changing the title of HBASE-18770 I remember that the 
bypass method is also used in MasterCoprocessor...

> Cleanup bypass semantic in MasterCoprocessorHost
> 
>
> Key: HBASE-15071
> URL: https://issues.apache.org/jira/browse/HBASE-15071
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Umesh Agashe
>Priority: Blocker
> Attachments: HBASE-15071.patch
>
>
> Lets decide on this one before we release 2.0.0.
> A bunch of methods in MasterCoprocessorHost on the 'pre' step allow returning 
> true which indicates the method invocation is not to proceed.
> Not all 'pre' steps do this. Just some.
> Seems a little arbitrary.
> How we skip out if we are not proceed with the invocation is also a little 
> arbitrary.
> When a deleteColumn call is supposed to skip out, it returns a -1, a 
> non-procId. If we are to skip a balance call, we log that CP said skip and 
> then return false to indicate the balancer did not run (why?). Elsewhere we 
> just exit silently. In createNamespace we used to exit silently but 
> HBASE-14888 just changed it so we throw a BypassCoprocessorException 
> instead... 
> Lets make them all work the same way.
> (This issue comes of chat w/ Matteo)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19001) Remove the hooks in RegionObserver which are designed to construct a StoreScanner which is marked as IA.Private

[Duo Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang updated HBASE-19001:
--
Release Note: 
These methods are removed:
KeyValueScanner 
preStoreScannerOpen(ObserverContext c,
  Store store, Scan scan, NavigableSet targetCols, KeyValueScanner 
s, long readPt)
  throws IOException;
InternalScanner 
preFlushScannerOpen(ObserverContext c,
  Store store, List scanners, InternalScanner s, long 
readPoint)
  throws IOException;
InternalScanner 
preCompactScannerOpen(ObserverContext c,
  Store store, List scanners, ScanType scanType, 
long earliestPutTs,
  InternalScanner s, CompactionLifeCycleTracker tracker, CompactionRequest 
request,
  long readPoint) throws IOException;

For flush and compaction, CP users are expected to wrap the InternalScanner in 
preFlush/preCompact. And for normal region operation, just use 
preGetOp/preScannerOpen to modify the Get/Scan object.

This method in Region interface is also removed as we do not need to use read 
point in CP hooks anymore:
long getReadPoint(IsolationLevel isolationLevel);

  was:
These methods are removed:
KeyValueScanner 
preStoreScannerOpen(ObserverContext c,
  Store store, Scan scan, NavigableSet targetCols, KeyValueScanner 
s, long readPt)
  throws IOException;
InternalScanner 
preFlushScannerOpen(ObserverContext c,
  Store store, List scanners, InternalScanner s, long 
readPoint)
  throws IOException;
InternalScanner 
preCompactScannerOpen(ObserverContext c,
  Store store, List scanners, ScanType scanType, 
long earliestPutTs,
  InternalScanner s, CompactionLifeCycleTracker tracker, CompactionRequest 
request,
  long readPoint) throws IOException;

For flush and compaction, CP users are expected to wrap the InternalScanner in 
preFlush/preCompact. And for normal region operation, just use 
preGetOp/preScannerOpen to modify the Get/Scan object.


> Remove the hooks in RegionObserver which are designed to construct a 
> StoreScanner which is marked as IA.Private
> ---
>
> Key: HBASE-19001
> URL: https://issues.apache.org/jira/browse/HBASE-19001
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19001-v1.patch, HBASE-19001-v2.patch, 
> HBASE-19001.patch
>
>
> There are three methods here
> {code}
> KeyValueScanner 
> preStoreScannerOpen(ObserverContext c,
>   Store store, Scan scan, NavigableSet targetCols, 
> KeyValueScanner s, long readPt)
>   throws IOException;
> InternalScanner 
> preFlushScannerOpen(ObserverContext c,
>   Store store, List scanners, InternalScanner s, long 
> readPoint)
>   throws IOException;
> InternalScanner 
> preCompactScannerOpen(ObserverContext c,
>   Store store, List scanners, ScanType 
> scanType, long earliestPutTs,
>   InternalScanner s, CompactionLifeCycleTracker tracker, 
> CompactionRequest request,
>   long readPoint) throws IOException;
> {code}
> For the flush and compact ones, we've discussed many times, it is not safe to 
> let user inject a Filter or even implement their own InternalScanner using 
> the store file scanners, as our correctness highly depends on the complicated 
> logic in SQM and StoreScanner. CP users are expected to wrap the original 
> InternalScanner(it is a StoreScanner anyway) in preFlush/preCompact methods 
> to do filtering or something else.
> For preStoreScannerOpen it even returns a KeyValueScanner which is marked as 
> IA.Private... This is less hurt but still, we've decided to not expose 
> StoreScanner to CP users so here this method is useless. CP users can use 
> preGetOp and preScannerOpen method to modify the Get/Scan object passed in to 
> inject into the scan operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18945) Make a IA.LimitedPrivate interface for CellComparator

[Ted Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208744#comment-16208744
 ] 

Ted Yu commented on HBASE-18945:


Ram didn't run patch for branch-2 thru QA.

> Make a IA.LimitedPrivate interface for CellComparator
> -
>
> Key: HBASE-18945
> URL: https://issues.apache.org/jira/browse/HBASE-18945
> Project: HBase
>  Issue Type: Sub-task
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0-alpha-4
>
> Attachments: 18945-addendum-branch-2.txt, HBASE-18495.patch, 
> HBASE-18945_2.patch, HBASE-18945_3.patch, HBASE-18945_4.patch, 
> HBASE-18945_5.patch, HBASE-18945_6.patch, HBASE-18945_6.patch, 
> HBASE-18945_7.patch
>
>
> Based on discussions over in HBASE-18826 and HBASE-18183 it is better we 
> expose CellComparator as a public interface so that it could be used in 
> Region/Store interfaces to be exposed to CPs.
> Currently the Comparator is exposed in Region, STore and StoreFile. There is 
> another discussion whether to expose it at all layers or only at Region. 
> However since we are exposing this to CPs CellComparator being @Private is 
> not the ideal way to do it. We have to change it to LimitedPrivate. But 
> CellComparator has lot of additional methods which are internal (like where a 
> Cell is compared with an incoming byte[] used in index comparsions etc).
> One way to expose is that as being done now in HBASE-18826 - by exposing the 
> return type as Comparator. But this is not powerful. It only allows to 
> compare cells. So we try to expose an IA.LimitedPrivate interface that is 
> more powerful and allows comparing individual cell components also. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19001) Remove the hooks in RegionObserver which are designed to construct a StoreScanner which is marked as IA.Private

[Duo Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208742#comment-16208742
 ] 

Duo Zhang commented on HBASE-19001:
---

Filed HBASE-19033 to address the follow on problem. Will commit this shortly.

> Remove the hooks in RegionObserver which are designed to construct a 
> StoreScanner which is marked as IA.Private
> ---
>
> Key: HBASE-19001
> URL: https://issues.apache.org/jira/browse/HBASE-19001
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19001-v1.patch, HBASE-19001-v2.patch, 
> HBASE-19001.patch
>
>
> There are three methods here
> {code}
> KeyValueScanner 
> preStoreScannerOpen(ObserverContext c,
>   Store store, Scan scan, NavigableSet targetCols, 
> KeyValueScanner s, long readPt)
>   throws IOException;
> InternalScanner 
> preFlushScannerOpen(ObserverContext c,
>   Store store, List scanners, InternalScanner s, long 
> readPoint)
>   throws IOException;
> InternalScanner 
> preCompactScannerOpen(ObserverContext c,
>   Store store, List scanners, ScanType 
> scanType, long earliestPutTs,
>   InternalScanner s, CompactionLifeCycleTracker tracker, 
> CompactionRequest request,
>   long readPoint) throws IOException;
> {code}
> For the flush and compact ones, we've discussed many times, it is not safe to 
> let user inject a Filter or even implement their own InternalScanner using 
> the store file scanners, as our correctness highly depends on the complicated 
> logic in SQM and StoreScanner. CP users are expected to wrap the original 
> InternalScanner(it is a StoreScanner anyway) in preFlush/preCompact methods 
> to do filtering or something else.
> For preStoreScannerOpen it even returns a KeyValueScanner which is marked as 
> IA.Private... This is less hurt but still, we've decided to not expose 
> StoreScanner to CP users so here this method is useless. CP users can use 
> preGetOp and preScannerOpen method to modify the Get/Scan object passed in to 
> inject into the scan operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19033) Allow CP users to change versions and TTL before opening StoreScanner

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-19033:
-

 Summary: Allow CP users to change versions and TTL before opening 
StoreScanner
 Key: HBASE-19033
 URL: https://issues.apache.org/jira/browse/HBASE-19033
 Project: HBase
  Issue Type: Sub-task
  Components: Coprocessors
Reporter: Duo Zhang


See the discussion in HBASE-19001. Changing versions and TTL is safe for 
flush/compaction so we can expose them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18945) Make a IA.LimitedPrivate interface for CellComparator

[Josh Elser (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208738#comment-16208738
 ] 

Josh Elser commented on HBASE-18945:


[~tedyu], why didn't PreCommit catch this?

> Make a IA.LimitedPrivate interface for CellComparator
> -
>
> Key: HBASE-18945
> URL: https://issues.apache.org/jira/browse/HBASE-18945
> Project: HBase
>  Issue Type: Sub-task
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0-alpha-4
>
> Attachments: 18945-addendum-branch-2.txt, HBASE-18495.patch, 
> HBASE-18945_2.patch, HBASE-18945_3.patch, HBASE-18945_4.patch, 
> HBASE-18945_5.patch, HBASE-18945_6.patch, HBASE-18945_6.patch, 
> HBASE-18945_7.patch
>
>
> Based on discussions over in HBASE-18826 and HBASE-18183 it is better we 
> expose CellComparator as a public interface so that it could be used in 
> Region/Store interfaces to be exposed to CPs.
> Currently the Comparator is exposed in Region, STore and StoreFile. There is 
> another discussion whether to expose it at all layers or only at Region. 
> However since we are exposing this to CPs CellComparator being @Private is 
> not the ideal way to do it. We have to change it to LimitedPrivate. But 
> CellComparator has lot of additional methods which are internal (like where a 
> Cell is compared with an incoming byte[] used in index comparsions etc).
> One way to expose is that as being done now in HBASE-18826 - by exposing the 
> return type as Comparator. But this is not powerful. It only allows to 
> compare cells. So we try to expose an IA.LimitedPrivate interface that is 
> more powerful and allows comparing individual cell components also. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19002) Introduce more examples to show how to intercept normal region operations

[Duo Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208731#comment-16208731
 ] 

Duo Zhang commented on HBASE-19002:
---

Just write some simple examples in the hbase-examples module.

I think this is not a blocker of alpha4, although I prefer finishing this 
before alpha4 to make sure that our approach of CP API cleanup is correct and 
can still provide the ability we want.

> Introduce more examples to show how to intercept normal region operations
> -
>
> Key: HBASE-19002
> URL: https://issues.apache.org/jira/browse/HBASE-19002
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
> Fix For: 2.0.0-alpha-4
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19001) Remove the hooks in RegionObserver which are designed to construct a StoreScanner which is marked as IA.Private

[Duo Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208728#comment-16208728
 ] 

Duo Zhang commented on HBASE-19001:
---

{quote}
On the table if they set, the issue is this will be honored at the time of 
actual scan from client side also. So the client side scan objects also has to 
specify this 'n' max versions.
{quote}
There is no such problem. The default behavior is reading the latest version 
only. If you want to read more versions you need to set it explicitly on the 
Scan or Get object. And for the CP users, you must inject every where to filter 
out the cells which is only supposed to use at an intermediate state, so if you 
do not specify it on the family config, then you need to manually reset the 
versions every where also. This just adds more complexity I think.

Anyway, I think we can expose some configs in ScanInfo object to CP users, at 
least changing versions and ttl is safe I think. And the good things maybe 
that, a end user can get the correct actual versions information directly from 
the metadata of the Table, and for CP implementation they do not need to use 
another option to indicate the actual versions. And when implementing the 
wrapper InternalScanner, I found that it is really a pain to do filtering by 
versions(TTL is simple) as we need to consider column change and row change and 
the cells returned by one next call may not be a full row. And also, 
preStoreScannerOpen maybe a good place to inject some simple logics as it is on 
the path of all read operations, such as Get, Scan,checkAndXXX, and even 
increment. If CP users only want to change the versions or TTL then injecting 
here is much easier than injecting every individual operations.

I could do this in a follow on issue, along with the constructor changes of 
StoreScanner(remove the Optional parameter!).

Thanks.

> Remove the hooks in RegionObserver which are designed to construct a 
> StoreScanner which is marked as IA.Private
> ---
>
> Key: HBASE-19001
> URL: https://issues.apache.org/jira/browse/HBASE-19001
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19001-v1.patch, HBASE-19001-v2.patch, 
> HBASE-19001.patch
>
>
> There are three methods here
> {code}
> KeyValueScanner 
> preStoreScannerOpen(ObserverContext c,
>   Store store, Scan scan, NavigableSet targetCols, 
> KeyValueScanner s, long readPt)
>   throws IOException;
> InternalScanner 
> preFlushScannerOpen(ObserverContext c,
>   Store store, List scanners, InternalScanner s, long 
> readPoint)
>   throws IOException;
> InternalScanner 
> preCompactScannerOpen(ObserverContext c,
>   Store store, List scanners, ScanType 
> scanType, long earliestPutTs,
>   InternalScanner s, CompactionLifeCycleTracker tracker, 
> CompactionRequest request,
>   long readPoint) throws IOException;
> {code}
> For the flush and compact ones, we've discussed many times, it is not safe to 
> let user inject a Filter or even implement their own InternalScanner using 
> the store file scanners, as our correctness highly depends on the complicated 
> logic in SQM and StoreScanner. CP users are expected to wrap the original 
> InternalScanner(it is a StoreScanner anyway) in preFlush/preCompact methods 
> to do filtering or something else.
> For preStoreScannerOpen it even returns a KeyValueScanner which is marked as 
> IA.Private... This is less hurt but still, we've decided to not expose 
> StoreScanner to CP users so here this method is useless. CP users can use 
> preGetOp and preScannerOpen method to modify the Get/Scan object passed in to 
> inject into the scan operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18770) Remove bypass method in ObserverContext and implement the 'bypass' logic case by case

[Duo Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang updated HBASE-18770:
--
Description: http://search-hadoop.com/m/HBase/YGbbXd0RDCIHSC1  (was: As now 
we do not allow users to create a StoreFile instance. Users can still select 
the files to be bulk loaded by modifying the familyPaths passed in.)

> Remove bypass method in ObserverContext and implement the 'bypass' logic case 
> by case
> -
>
> Key: HBASE-18770
> URL: https://issues.apache.org/jira/browse/HBASE-18770
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
> Fix For: 2.0.0-alpha-4
>
>
> http://search-hadoop.com/m/HBase/YGbbXd0RDCIHSC1



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1

[Lars Hofhansl (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208714#comment-16208714
 ] 

Lars Hofhansl edited comment on HBASE-15631 at 10/18/17 2:08 AM:
-

Cool! I'm fairly sure now that this will leave existing functionality alone (- 
the coprocessor changes, but look to be allowed per our compatibility matrix).

The {{randomAssignment}} stuff in HMaster was truly not needed?



was (Author: lhofhansl):
Cool! I'm fairly sure now that this will leave existing functionality alone (- 
the coprocessor changes, but look to be allowed per our compatibility matrix).

The {randomAssignment} stuff in HMaster was truly not needed?


> Backport Regionserver Groups (HBASE-6721) to branch-1 
> --
>
> Key: HBASE-15631
> URL: https://issues.apache.org/jira/browse/HBASE-15631
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 1.4.0
>Reporter: Francis Liu
>Assignee: Andrew Purtell
> Fix For: 1.4.0, 1.5.0
>
> Attachments: HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch, 
> HBASE-15631.branch-1.patch, HBASE-15631.patch
>
>
> Based on dev list discussion backporting region server group should not be an 
> issue as it does not: 1. destabilize the code. 2. cause backward 
> incompatibility. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1

[Lars Hofhansl (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208714#comment-16208714
 ] 

Lars Hofhansl commented on HBASE-15631:
---

Cool! I'm fairly sure now that this will leave existing functionality alone (- 
the coprocessor changes, but look to be allowed per our compatibility matrix).

The {randomAssignment} stuff in HMaster was truly not needed?


> Backport Regionserver Groups (HBASE-6721) to branch-1 
> --
>
> Key: HBASE-15631
> URL: https://issues.apache.org/jira/browse/HBASE-15631
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 1.4.0
>Reporter: Francis Liu
>Assignee: Andrew Purtell
> Fix For: 1.4.0, 1.5.0
>
> Attachments: HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch, 
> HBASE-15631.branch-1.patch, HBASE-15631.patch
>
>
> Based on dev list discussion backporting region server group should not be an 
> issue as it does not: 1. destabilize the code. 2. cause backward 
> incompatibility. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18770) Remove bypass method in ObserverContext and implement the 'bypass' logic case by case

[Duo Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang updated HBASE-18770:
--
Summary: Remove bypass method in ObserverContext and implement the 'bypass' 
logic case by case  (was: We should not allow RegionObserver.preBulkLoadHFile 
to bypass the default behavior)

> Remove bypass method in ObserverContext and implement the 'bypass' logic case 
> by case
> -
>
> Key: HBASE-18770
> URL: https://issues.apache.org/jira/browse/HBASE-18770
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Duo Zhang
> Fix For: 2.0.0-alpha-4
>
>
> As now we do not allow users to create a StoreFile instance. Users can still 
> select the files to be bulk loaded by modifying the familyPaths passed in.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19010) Reimplement getMasterInfoPort for Admin

[Guanghao Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guanghao Zhang updated HBASE-19010:
---
Attachment: HBASE-19010.master.002.patch

Retry for Hadoop QA.

> Reimplement getMasterInfoPort for Admin
> ---
>
> Key: HBASE-19010
> URL: https://issues.apache.org/jira/browse/HBASE-19010
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19010.master.001.patch, 
> HBASE-19010.master.002.patch, HBASE-19010.master.002.patch, 
> HBASE-19010.master.002.patch
>
>
> Current implementation.
> {code}
>   public int getMasterInfoPort() throws IOException {
> // TODO: Fix!  Reaching into internal implementation
> ConnectionImplementation connection = 
> (ConnectionImplementation)this.connection;
> ZooKeeperKeepAliveConnection zkw = 
> connection.getKeepAliveZooKeeperWatcher();
> try {
>   return MasterAddressTracker.getMasterInfoPort(zkw);
> } catch (KeeperException e) {
>   throw new IOException("Failed to get master info port from 
> MasterAddressTracker", e);
> }
>   }
> {code}
> Open this issue to fix TODO.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18893) Remove Add/Modify/DeleteColumnFamilyProcedure in favor of using ModifyTableProcedure

[Mike Drob (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob updated HBASE-18893:
--
Attachment: HBASE-18893.v2.patch

v2: remove the hooks from MasterObserver as well

> Remove Add/Modify/DeleteColumnFamilyProcedure in favor of using 
> ModifyTableProcedure
> 
>
> Key: HBASE-18893
> URL: https://issues.apache.org/jira/browse/HBASE-18893
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors, master
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18893.patch, HBASE-18893.v2.patch
>
>
> The shell changed from using separate add/modify/delete column calls to 
> funneling everything through modify table for performance reasons. We know 
> that using modify table works for everything. Let's drop the old code for 
> Add/Modify/Delete Column so that we have a lower maintenance burden and fewer 
> code paths to reason about.
>  Was: shell 'alter' command no longer distinguishes column 
> add/modify/delete
> After HBASE-15641 all 'alter' commands go through a single modifyTable call 
> at the end, so we no longer can easily distinguish add, modify, and delete 
> column events. This potentially affects coprocessors that needed the update 
> notifications for new or removed columns.
> Let's let the shell still make separate behaviour calls like it did before 
> without undoing the batching that seems pretty useful.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18350) RSGroups are broken under AMv2

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208691#comment-16208691
 ] 

Hudson commented on HBASE-18350:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3906 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/3906/])
HBASE-18350 RSGroups are broken under AMv2 (stack: rev 
41cc9a125f0074bdb9633d873f5bc2219ca1fb73)
* (edit) 
hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupBasedLoadBalancer.java
* (edit) hbase-shell/src/main/ruby/shell/commands/get_rsgroup.rb
* (edit) hbase-shell/src/main/ruby/hbase/rsgroup_admin.rb
* (edit) hbase-server/src/main/resources/hbase-webapps/master/table.jsp
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/ProcedureSyncWait.java
* (edit) hbase-shell/src/main/ruby/shell/commands/move_servers_rsgroup.rb
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/master/assignment/AssignmentManager.java
* (edit) 
hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupAdminServer.java
* (edit) 
hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/rsgroup/TestRSGroupsOfflineMode.java
* (edit) 
hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/rsgroup/TestRSGroups.java
* (edit) hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb


> RSGroups are broken under AMv2
> --
>
> Key: HBASE-18350
> URL: https://issues.apache.org/jira/browse/HBASE-18350
> Project: HBase
>  Issue Type: Bug
>  Components: rsgroup
>Affects Versions: 2.0.0-alpha-1
>Reporter: Stephen Yuan Jiang
>Assignee: Balazs Meszaros
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18350.master.001.patch, 
> HBASE-18350.master.002.patch, HBASE-18350.master.003.patch, 
> HBASE-18350.master.004.patch, HBASE-18350.master.004.patch, 
> HBASE-18350.master.004.patch, HBASE-18350.master.005.patch, 
> HBASE-18350.master.006.patch, HBASE-18350.master.006.patch
>
>
> The following RSGroups tests were disabled by Core Proc-V2 AM in HBASE-14614:
> - Disabled/Ignore TestRSGroupsOfflineMode#testOffline; need to dig in on what 
> offline is.
> - Disabled/Ignore TestRSGroups.
> This JIRA tracks the work to enable them (or remove/modify if not applicable).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18960) A few bug fixes and minor improvements around batchMutate()

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208690#comment-16208690
 ] 

Hudson commented on HBASE-18960:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3906 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/3906/])
HBASE-18960 A few bug fixes and minor improvements around batchMutate (stack: 
rev e1941aa6d14afd116a555fc93a3149f3e7c20af2)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionReplayEvents.java


> A few bug fixes and minor improvements around batchMutate()
> ---
>
> Key: HBASE-18960
> URL: https://issues.apache.org/jira/browse/HBASE-18960
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0-alpha-3
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0-alpha-4
>
> Attachments: hbase-18960.master.001.patch, 
> hbase-18960.master.002.patch, hbase-18960.master.003.patch, 
> hbase-18960.master.004.patch, hbase-18960.master.005.patch, 
> hbase-18960.master.005.patch, hbase-18960.master.006.patch, 
> hbase-18960.master.007.patch, hbase-18960.master.008.patch, 
> hbase-18960.master.009.patch
>
>
> Batch validation and preparation can be done before we start iterating over 
> batch operations for writes. observedExceptions, familyCellMaps and 
> durability can be stored in BatchOperation as they are batch wide. For all 
> operations, done by preBatchMutate() CP hook, operation status needs to be 
> SUCCESS. Modify and use doWALAppend() from doMiniBatchMutate().



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18893) Remove Add/Modify/DeleteColumnFamilyProcedure in favor of using ModifyTableProcedure

[Mike Drob (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208687#comment-16208687
 ] 

Mike Drob commented on HBASE-18893:
---

Hit a snag - while working on this I discovered that {{AccessController}} uses 
the preXXX hooks to authorize add/modify/remove of column families. This 
behavior is _also_ currently broken by the same shell change that I brought up 
earlier, since that will no longer use the same code path.

We can delete those permissions and release note it, but maybe we need a 
gentler touch?

> Remove Add/Modify/DeleteColumnFamilyProcedure in favor of using 
> ModifyTableProcedure
> 
>
> Key: HBASE-18893
> URL: https://issues.apache.org/jira/browse/HBASE-18893
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors, master
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18893.patch
>
>
> The shell changed from using separate add/modify/delete column calls to 
> funneling everything through modify table for performance reasons. We know 
> that using modify table works for everything. Let's drop the old code for 
> Add/Modify/Delete Column so that we have a lower maintenance burden and fewer 
> code paths to reason about.
>  Was: shell 'alter' command no longer distinguishes column 
> add/modify/delete
> After HBASE-15641 all 'alter' commands go through a single modifyTable call 
> at the end, so we no longer can easily distinguish add, modify, and delete 
> column events. This potentially affects coprocessors that needed the update 
> notifications for new or removed columns.
> Let's let the shell still make separate behaviour calls like it did before 
> without undoing the batching that seems pretty useful.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208684#comment-16208684
 ] 

Hudson commented on HBASE-19032:


FAILURE: Integrated in Jenkins build HBase-1.4 #954 (See 
[https://builds.apache.org/job/HBase-1.4/954/])
HBASE-19032 Set mimetype for patches uploaded by submit-patch.py (appy: rev 
b7000706a4280cdf7aeb5db669d2732483b18714)
* (edit) dev-support/submit-patch.py


> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-13346) Clean up Filter package for post 1.0 s/KeyValue/Cell/g

[Mike Drob (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208682#comment-16208682
 ] 

Mike Drob commented on HBASE-13346:
---

Skimmed it, patch makes sense and looks fine to me. Do we need to address this 
comment by [~openinx]:
bq. Do we need to wait util branch HBASE-18410 merged into master branch before 
we commit this patch into master ? Otherwise, there will be many conflicts when 
merging master with branch HBASE-18410, and we need to resolve the conflicts, 
workload may be the same as the workload of re-preparing a patch for this issue 
?


> Clean up Filter package for post 1.0 s/KeyValue/Cell/g
> --
>
> Key: HBASE-13346
> URL: https://issues.apache.org/jira/browse/HBASE-13346
> Project: HBase
>  Issue Type: Bug
>  Components: API, Filters
>Affects Versions: 2.0.0
>Reporter: Lars George
>Assignee: Tamas Penzes
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-13346.master.001.patch, 
> HBASE-13346.master.002.patch, HBASE-13346.master.003.patch, 
> HBASE-13346.master.003.patch, HBASE-13346.master.004.patch, 
> HBASE-13346.master.005.patch, HBASE-13346.master.006.patch, 
> HBASE-13346.master.007.patch, HBASE-13346.master.008.patch
>
>
> Since we have a bit of a messy Filter API with KeyValue vs Cell reference 
> mixed up all over the place, I recommend cleaning this up once and for all. 
> There should be no {{KeyValue}} (or {{kv}}, {{kvs}} etc.) in any method or 
> parameter name.
> This includes deprecating and renaming filters too, for example 
> {{FirstKeyOnlyFilter}}, which really should be named {{FirstKeyValueFilter}} 
> as it does _not_ just return the key, but the entire cell. It should be 
> deprecated and renamed to {{FirstCellFilter}} (or {{FirstColumnFilter}} if 
> you prefer).
> In general we should clarify and settle on {{KeyValue}} vs {{Cell}} vs 
> {{Column}} in our naming. The latter two are the only ones going forward with 
> the public API, and are used synonymous. We should carefully check which is 
> better suited (is it really a specific cell, or the newest cell, aka the 
> newest column value) and settle on a naming schema.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18760) Make hbase-shaded-check-invariants part of precommit

[Mike Drob (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208680#comment-16208680
 ] 

Mike Drob commented on HBASE-18760:
---

Right, we were failing on it before and didn't seem to be missing anything. +1 
to remove. 

> Make hbase-shaded-check-invariants part of precommit
> 
>
> Key: HBASE-18760
> URL: https://issues.apache.org/jira/browse/HBASE-18760
> Project: HBase
>  Issue Type: Test
>  Components: community, test
>Reporter: Appy
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 3.0.0
>
> Attachments: HBASE-18760.0.patch, HBASE-18760.1.patch, 
> HBASE-18760.2.patch, HBASE-18760.3.patch, HBASE-18760.addendum.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18601) Update Htrace to 4.2

[Mike Drob (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208681#comment-16208681
 ] 

Mike Drob commented on HBASE-18601:
---

Probably the same issue I ran into over on HBASE-16338 (scroll down to the way 
bottom)

> Update Htrace to 4.2
> 
>
> Key: HBASE-18601
> URL: https://issues.apache.org/jira/browse/HBASE-18601
> Project: HBase
>  Issue Type: Task
>Affects Versions: 2.0.0, 3.0.0
>Reporter: Tamas Penzes
>Assignee: Tamas Penzes
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18601.master.001.patch, 
> HBASE-18601.master.002.patch, HBASE-18601.master.003 (3).patch, 
> HBASE-18601.master.003.patch, HBASE-18601.master.004.patch, 
> HBASE-18601.master.004.patch, HBASE-18601.master.005.patch, 
> HBASE-18601.master.006.patch, HBASE-18601.master.006.patch, 
> HBASE-18601.master.007.patch, HBASE-18601.master.007.patch, 
> HBASE-18601.master.007.patch, HBASE-18601.master.008.patch, 
> HBASE-18601.master.009.patch, HBASE-18601.master.009.patch, 
> HBASE-18601.master.010.patch, HBASE-18601.master.010.patch
>
>
> HTrace is not perfectly integrated into HBase, the version 3.2.0 is buggy, 
> the upgrade to 4.x is not trivial and would take time. It might not worth to 
> keep it in this state, so would be better to remove it.
> Of course it doesn't mean tracing would be useless, just that in this form 
> the use of HTrace 3.2 might not add any value to the project and fixing it 
> would be far too much effort.
> -
> Based on the decision of the community we keep htrace now and update version



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208618#comment-16208618
 ] 

Hadoop QA commented on HBASE-15631:
---

| (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}  3m 
30s{color} | {color:red} Docker failed to build yetus/hbase:6f1cc2c. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-15631 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12892712/HBASE-15631-branch-1.patch
 |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9172/console |
| Powered by | Apache Yetus 0.4.0   http://yetus.apache.org |


This message was automatically generated.



> Backport Regionserver Groups (HBASE-6721) to branch-1 
> --
>
> Key: HBASE-15631
> URL: https://issues.apache.org/jira/browse/HBASE-15631
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 1.4.0
>Reporter: Francis Liu
>Assignee: Andrew Purtell
> Fix For: 1.4.0, 1.5.0
>
> Attachments: HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch, 
> HBASE-15631.branch-1.patch, HBASE-15631.patch
>
>
> Based on dev list discussion backporting region server group should not be an 
> issue as it does not: 1. destabilize the code. 2. cause backward 
> incompatibility. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1

[Andrew Purtell (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208612#comment-16208612
 ] 

Andrew Purtell edited comment on HBASE-15631 at 10/17/17 11:59 PM:
---

Address additional review feedback and minor improvements:

- Drop unnecessary changes from HMaster
- Drop unnecessary changes from MasterRpcServices
- Drop unwanted changes from ProtobufUtil
- Drop reintroduction of HostAndPort to ServerName
- Move RSGroupInfo from hbase-common to hbase-rsgroup
- Make supportGroupCPs private in MasterCoprocessorHost

[~lhofhansl]



was (Author: apurtell):
Address additional review feedback and minor improvements:

- Drop unnecessary changes from HMaster
- Drop unnecessary changes from MasterRpcServices
- Drop unwanted changes from ProtobufUtil
- Drop reintroduction of HostAndPort to ServerName
- Move RSGroupInfo from hbase-common to hbase-rsgroup
- Make supportGroupCPs private in MasterCoprocessorHost


> Backport Regionserver Groups (HBASE-6721) to branch-1 
> --
>
> Key: HBASE-15631
> URL: https://issues.apache.org/jira/browse/HBASE-15631
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 1.4.0
>Reporter: Francis Liu
>Assignee: Andrew Purtell
> Fix For: 1.4.0, 1.5.0
>
> Attachments: HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch, 
> HBASE-15631.branch-1.patch, HBASE-15631.patch
>
>
> Based on dev list discussion backporting region server group should not be an 
> issue as it does not: 1. destabilize the code. 2. cause backward 
> incompatibility. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1

[Andrew Purtell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-15631:
---
Attachment: HBASE-15631-branch-1.patch

Address additional review feedback and minor improvements:

- Drop unnecessary changes from HMaster
- Drop unnecessary changes from MasterRpcServices
- Drop unwanted changes from ProtobufUtil
- Drop reintroduction of HostAndPort to ServerName
- Move RSGroupInfo from hbase-common to hbase-rsgroup
- Make supportGroupCPs private in MasterCoprocessorHost


> Backport Regionserver Groups (HBASE-6721) to branch-1 
> --
>
> Key: HBASE-15631
> URL: https://issues.apache.org/jira/browse/HBASE-15631
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 1.4.0
>Reporter: Francis Liu
>Assignee: Francis Liu
> Fix For: 1.4.0, 1.5.0
>
> Attachments: HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch, 
> HBASE-15631.branch-1.patch, HBASE-15631.patch
>
>
> Based on dev list discussion backporting region server group should not be an 
> issue as it does not: 1. destabilize the code. 2. cause backward 
> incompatibility. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1

[Andrew Purtell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell reassigned HBASE-15631:
--

Assignee: Andrew Purtell  (was: Francis Liu)

> Backport Regionserver Groups (HBASE-6721) to branch-1 
> --
>
> Key: HBASE-15631
> URL: https://issues.apache.org/jira/browse/HBASE-15631
> Project: HBase
>  Issue Type: New Feature
>Affects Versions: 1.4.0
>Reporter: Francis Liu
>Assignee: Andrew Purtell
> Fix For: 1.4.0, 1.5.0
>
> Attachments: HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch, 
> HBASE-15631.branch-1.patch, HBASE-15631.patch
>
>
> Based on dev list discussion backporting region server group should not be an 
> issue as it does not: 1. destabilize the code. 2. cause backward 
> incompatibility. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18984) [AMv2] Retain assignment does not work well in AMv2

[Yi Liang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yi Liang updated HBASE-18984:
-
Attachment: HBASE-18984-V1-master.patch

> [AMv2] Retain assignment does not work well in AMv2
> ---
>
> Key: HBASE-18984
> URL: https://issues.apache.org/jira/browse/HBASE-18984
> Project: HBase
>  Issue Type: Bug
>  Components: proc-v2
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: HBASE-18984-V1-master.patch, Screen Shot 2017-10-10 at 
> 2.24.19 PM.png
>
>
> work on 8.17 Retain assignment in 
> https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.epjn9nege80k
> To reproduce this error, in hbase shell:
> createTable t1 --> list_regions 't1' --> disable 't1' ---> enable 't1' --> 
> list_reigons 't1' (maybe you need to try enable/disable multiple times)
> See attached images. same region assigned to different region servers



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18984) [AMv2] Retain assignment does not work well in AMv2

[Yi Liang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yi Liang updated HBASE-18984:
-
Attachment: (was: HBASE-18984-V1-master.patch)

> [AMv2] Retain assignment does not work well in AMv2
> ---
>
> Key: HBASE-18984
> URL: https://issues.apache.org/jira/browse/HBASE-18984
> Project: HBase
>  Issue Type: Bug
>  Components: proc-v2
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: Screen Shot 2017-10-10 at 2.24.19 PM.png
>
>
> work on 8.17 Retain assignment in 
> https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.epjn9nege80k
> To reproduce this error, in hbase shell:
> createTable t1 --> list_regions 't1' --> disable 't1' ---> enable 't1' --> 
> list_reigons 't1' (maybe you need to try enable/disable multiple times)
> See attached images. same region assigned to different region servers



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18906) Investigate Phoenix usages of Region#waitForXXX APIs

[Sergey Soldatov (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208608#comment-16208608
 ] 

Sergey Soldatov commented on HBASE-18906:
-

Well, I would completely agree with [~andrew.purt...@gmail.com] that not only 
Phoenix, but any coprocessor might benefit from that API. As for Phoenix we 
rarely have to create workarounds and even if we do it, we file a new jira for 
HBase (you may check the Phoenix code and find a lot of references to HBase 
jiras). 

> Investigate Phoenix usages of Region#waitForXXX APIs
> 
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-18601) Update Htrace to 4.2

[Tamas Penzes (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208604#comment-16208604
 ] 

Tamas Penzes edited comment on HBASE-18601 at 10/17/17 11:47 PM:
-

Hi,

Does anybody have some idea why we get this:
{code}
[INFO] --- maven-compiler-plugin:3.6.1:compile (default-compile) @ hbase-rest 
---
[INFO] Compiling 70 source files to /testptch/hbase/hbase-rest/target/classes
[INFO] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java:
 Some input files use or override a deprecated API.
[INFO] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java:
 Recompile with -Xlint:deprecation for details.
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[23,31]
 cannot find symbol
  symbol:   class CompatibilitySingletonFactory
  location: package org.apache.hadoop.hbase
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[25,36]
 cannot find symbol
  symbol:   class MetricsRESTSource
  location: package org.apache.hadoop.hbase.rest
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[30,10]
 cannot find symbol
  symbol:   class MetricsRESTSource
  location: class org.apache.hadoop.hbase.rest.MetricsREST
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[34,11]
 cannot find symbol
  symbol:   class MetricsRESTSource
  location: class org.apache.hadoop.hbase.rest.MetricsREST
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[37,57]
 cannot find symbol
  symbol:   class MetricsRESTSource
  location: class org.apache.hadoop.hbase.rest.MetricsREST
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[37,15]
 cannot find symbol
  symbol:   variable CompatibilitySingletonFactory
  location: class org.apache.hadoop.hbase.rest.MetricsREST
[INFO] 6 errors 
{code}

 It builds/runs for me locally, if we didn't have these resources, it would not 
build for me either.
Thanks.


was (Author: tamaas):
Hi,

Does anybody have some idea why we get this:
{code}
[INFO] --- maven-compiler-plugin:3.6.1:compile (default-compile) @ hbase-rest 
---
[INFO] Compiling 70 source files to /testptch/hbase/hbase-rest/target/classes
[INFO] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java:
 Some input files use or override a deprecated API.
[INFO] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java:
 Recompile with -Xlint:deprecation for details.
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[23,31]
 cannot find symbol
  symbol:   class CompatibilitySingletonFactory
  location: package org.apache.hadoop.hbase
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[25,36]
 cannot find symbol
  symbol:   class MetricsRESTSource
  location: package org.apache.hadoop.hbase.rest
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[30,10]
 cannot find symbol
  symbol:   class MetricsRESTSource
  location: class org.apache.hadoop.hbase.rest.MetricsREST
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[34,11]
 cannot find symbol
  symbol:   class MetricsRESTSource
  location: class org.apache.hadoop.hbase.rest.MetricsREST
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[37,57]
 cannot find symbol
  symbol:   class MetricsRESTSource
  location: class org.apache.hadoop.hbase.rest.MetricsREST
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[37,15]
 cannot find symbol
  symbol:   variable CompatibilitySingletonFactory
  location: class org.apache.hadoop.hbase.rest.MetricsREST
[INFO] 6 errors 
{code}

 It builds/runs for me locally, if we didn't have these resources, it would not 
build for me either.

> Update Htrace to 4.2
> 
>
> Key: HBASE-18601
> URL: https://issues.apache.org/jira/browse/HBASE-18601
> Project: HBase
>  Issue Type: Task
>Affects Versions: 2.0.0, 3.0.0
>Reporter: Tamas Penzes
>Assignee: Tamas Penzes
> Fix For: 2.0.0-beta-1
>
> Attachments: 

[jira] [Commented] (HBASE-18601) Update Htrace to 4.2

[Tamas Penzes (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208604#comment-16208604
 ] 

Tamas Penzes commented on HBASE-18601:
--

Hi,

Does anybody have some idea why we get this:
{code}
[INFO] --- maven-compiler-plugin:3.6.1:compile (default-compile) @ hbase-rest 
---
[INFO] Compiling 70 source files to /testptch/hbase/hbase-rest/target/classes
[INFO] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java:
 Some input files use or override a deprecated API.
[INFO] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java:
 Recompile with -Xlint:deprecation for details.
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[23,31]
 cannot find symbol
  symbol:   class CompatibilitySingletonFactory
  location: package org.apache.hadoop.hbase
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[25,36]
 cannot find symbol
  symbol:   class MetricsRESTSource
  location: package org.apache.hadoop.hbase.rest
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[30,10]
 cannot find symbol
  symbol:   class MetricsRESTSource
  location: class org.apache.hadoop.hbase.rest.MetricsREST
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[34,11]
 cannot find symbol
  symbol:   class MetricsRESTSource
  location: class org.apache.hadoop.hbase.rest.MetricsREST
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[37,57]
 cannot find symbol
  symbol:   class MetricsRESTSource
  location: class org.apache.hadoop.hbase.rest.MetricsREST
[ERROR] 
/testptch/hbase/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/MetricsREST.java:[37,15]
 cannot find symbol
  symbol:   variable CompatibilitySingletonFactory
  location: class org.apache.hadoop.hbase.rest.MetricsREST
[INFO] 6 errors 
{code}

 It builds/runs for me locally, if we didn't have these resources, it would not 
build for me either.

> Update Htrace to 4.2
> 
>
> Key: HBASE-18601
> URL: https://issues.apache.org/jira/browse/HBASE-18601
> Project: HBase
>  Issue Type: Task
>Affects Versions: 2.0.0, 3.0.0
>Reporter: Tamas Penzes
>Assignee: Tamas Penzes
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18601.master.001.patch, 
> HBASE-18601.master.002.patch, HBASE-18601.master.003 (3).patch, 
> HBASE-18601.master.003.patch, HBASE-18601.master.004.patch, 
> HBASE-18601.master.004.patch, HBASE-18601.master.005.patch, 
> HBASE-18601.master.006.patch, HBASE-18601.master.006.patch, 
> HBASE-18601.master.007.patch, HBASE-18601.master.007.patch, 
> HBASE-18601.master.007.patch, HBASE-18601.master.008.patch, 
> HBASE-18601.master.009.patch, HBASE-18601.master.009.patch, 
> HBASE-18601.master.010.patch, HBASE-18601.master.010.patch
>
>
> HTrace is not perfectly integrated into HBase, the version 3.2.0 is buggy, 
> the upgrade to 4.x is not trivial and would take time. It might not worth to 
> keep it in this state, so would be better to remove it.
> Of course it doesn't mean tracing would be useless, just that in this form 
> the use of HTrace 3.2 might not add any value to the project and fixing it 
> would be far too much effort.
> -
> Based on the decision of the community we keep htrace now and update version



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19029) Align RPC timout methods in Table and AsyncTableBase

[Peter Somogyi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Somogyi updated HBASE-19029:
--
Release Note: 
Deprecate the following methods in Table:
- int getRpcTimeout()
- int getReadRpcTimeout()
- int getWriteRpcTimeout()
- int getOperationTimeout()

Add the following methods to Table:
- long getRpcTimeout(TimeUnit)
- long getReadRpcTimeout(TimeUnit)
- long getWriteRpcTimeout(TimeUnit)
- long getOperationTimeout(TimeUnit)

Add missing deprecation tag for long getRpcTimeout(TimeUnit unit) in 
AsyncTableBase

> Align RPC timout methods in Table and AsyncTableBase
> 
>
> Key: HBASE-19029
> URL: https://issues.apache.org/jira/browse/HBASE-19029
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client
>Affects Versions: 2.0.0-alpha-3
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19029.master.001.patch
>
>
> Table and AsyncTableBase have similar RPC timeout methods but the async 
> version supports TimeUtils to be passed.
> To align these 2 interfaces lets depricate the existing methods in Table and 
> add the ones that are currently in AsyncTableBase.
> These methods are the following:
> * long getRpcTimeout(TimeUnit unit)
> * long getReadRpcTimeout(TimeUnit unit)
> * long getWriteRpcTimeout(TimeUnit unit)
> * long getOperationTimeout(TimeUnit unit)
> We do not have {{long getScanTimeout(TimeUnit unit)}} since scan is handled 
> differently. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19029) Align RPC timout methods in Table and AsyncTableBase

[Peter Somogyi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Somogyi updated HBASE-19029:
--
Status: Patch Available  (was: Open)

> Align RPC timout methods in Table and AsyncTableBase
> 
>
> Key: HBASE-19029
> URL: https://issues.apache.org/jira/browse/HBASE-19029
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client
>Affects Versions: 2.0.0-alpha-3
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19029.master.001.patch
>
>
> Table and AsyncTableBase have similar RPC timeout methods but the async 
> version supports TimeUtils to be passed.
> To align these 2 interfaces lets depricate the existing methods in Table and 
> add the ones that are currently in AsyncTableBase.
> These methods are the following:
> * long getRpcTimeout(TimeUnit unit)
> * long getReadRpcTimeout(TimeUnit unit)
> * long getWriteRpcTimeout(TimeUnit unit)
> * long getOperationTimeout(TimeUnit unit)
> We do not have {{long getScanTimeout(TimeUnit unit)}} since scan is handled 
> differently. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18906) Investigate Phoenix usages of Region#waitForXXX APIs

[Josh Elser (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208595#comment-16208595
 ] 

Josh Elser commented on HBASE-18906:


bq. Maybe a shruggie would have been better. No desire to comment further.

Understood, Andrew. Sorry for bringing you back in again.

bq. I am not looking to defend against an adversarial questioning of what 
Phoenix might or might not be doing. I admit it's a bit unfair for me to bring 
this frustration to this issue where there is missing context, so I apologize 
for that.

I was definitely not trying to be argumentative here (sorry if I came across 
that way), just come up with a minimum set of things that would make sense to 
get into alpha-4 and not let scope creep more. Your consideration on good API 
design from the HBase POV (and the consideration for those downstream) is 
greatly appreciated by me.

> Investigate Phoenix usages of Region#waitForXXX APIs
> 
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18945) Make a IA.LimitedPrivate interface for CellComparator

[Ted Yu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-18945:
---
Attachment: 18945-addendum-branch-2.txt

> Make a IA.LimitedPrivate interface for CellComparator
> -
>
> Key: HBASE-18945
> URL: https://issues.apache.org/jira/browse/HBASE-18945
> Project: HBase
>  Issue Type: Sub-task
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0-alpha-4
>
> Attachments: 18945-addendum-branch-2.txt, HBASE-18495.patch, 
> HBASE-18945_2.patch, HBASE-18945_3.patch, HBASE-18945_4.patch, 
> HBASE-18945_5.patch, HBASE-18945_6.patch, HBASE-18945_6.patch, 
> HBASE-18945_7.patch
>
>
> Based on discussions over in HBASE-18826 and HBASE-18183 it is better we 
> expose CellComparator as a public interface so that it could be used in 
> Region/Store interfaces to be exposed to CPs.
> Currently the Comparator is exposed in Region, STore and StoreFile. There is 
> another discussion whether to expose it at all layers or only at Region. 
> However since we are exposing this to CPs CellComparator being @Private is 
> not the ideal way to do it. We have to change it to LimitedPrivate. But 
> CellComparator has lot of additional methods which are internal (like where a 
> Cell is compared with an incoming byte[] used in index comparsions etc).
> One way to expose is that as being done now in HBASE-18826 - by exposing the 
> return type as Comparator. But this is not powerful. It only allows to 
> compare cells. So we try to expose an IA.LimitedPrivate interface that is 
> more powerful and allows comparing individual cell components also. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19029) Align RPC timout methods in Table and AsyncTableBase

[Peter Somogyi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Somogyi updated HBASE-19029:
--
Attachment: HBASE-19029.master.001.patch

> Align RPC timout methods in Table and AsyncTableBase
> 
>
> Key: HBASE-19029
> URL: https://issues.apache.org/jira/browse/HBASE-19029
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client
>Affects Versions: 2.0.0-alpha-3
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19029.master.001.patch
>
>
> Table and AsyncTableBase have similar RPC timeout methods but the async 
> version supports TimeUtils to be passed.
> To align these 2 interfaces lets depricate the existing methods in Table and 
> add the ones that are currently in AsyncTableBase.
> These methods are the following:
> * long getRpcTimeout(TimeUnit unit)
> * long getReadRpcTimeout(TimeUnit unit)
> * long getWriteRpcTimeout(TimeUnit unit)
> * long getOperationTimeout(TimeUnit unit)
> We do not have {{long getScanTimeout(TimeUnit unit)}} since scan is handled 
> differently. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208578#comment-16208578
 ] 

Hudson commented on HBASE-19032:


SUCCESS: Integrated in Jenkins build HBase-1.2-IT #975 (See 
[https://builds.apache.org/job/HBase-1.2-IT/975/])
HBASE-19032 Set mimetype for patches uploaded by submit-patch.py (appy: rev 
6d03d25009d9fda2363fb5fe912fe43112336a65)
* (edit) dev-support/submit-patch.py


> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208574#comment-16208574
 ] 

Hudson commented on HBASE-19032:


FAILURE: Integrated in Jenkins build HBase-1.2-JDK8 #238 (See 
[https://builds.apache.org/job/HBase-1.2-JDK8/238/])
HBASE-19032 Set mimetype for patches uploaded by submit-patch.py (appy: rev 
6d03d25009d9fda2363fb5fe912fe43112336a65)
* (edit) dev-support/submit-patch.py


> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (HBASE-18945) Make a IA.LimitedPrivate interface for CellComparator

[Ted Yu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu reopened HBASE-18945:


Jenkins build for 2.0 fails with:
{code}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile (default-compile) 
on project hbase-mapreduce: Compilation failure: Compilation failure:
[ERROR] 
/home/jenkins/jenkins-slave/workspace/HBase-2.0/a3159d73/hbase-mapreduce/src/main/java/org/apache/hadoop/hbase/mapreduce/Import.java:[167,28]
 package CellComparator does not exist
[ERROR] 
/home/jenkins/jenkins-slave/workspace/HBase-2.0/a3159d73/hbase-mapreduce/src/main/java/org/apache/hadoop/hbase/mapreduce/KeyValueSortReducer.java:[45,57]
 cannot find symbol
[ERROR] symbol:   variable COMPARATOR
[ERROR] location: interface org.apache.hadoop.hbase.CellComparator
{code}

> Make a IA.LimitedPrivate interface for CellComparator
> -
>
> Key: HBASE-18945
> URL: https://issues.apache.org/jira/browse/HBASE-18945
> Project: HBase
>  Issue Type: Sub-task
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18495.patch, HBASE-18945_2.patch, 
> HBASE-18945_3.patch, HBASE-18945_4.patch, HBASE-18945_5.patch, 
> HBASE-18945_6.patch, HBASE-18945_6.patch, HBASE-18945_7.patch
>
>
> Based on discussions over in HBASE-18826 and HBASE-18183 it is better we 
> expose CellComparator as a public interface so that it could be used in 
> Region/Store interfaces to be exposed to CPs.
> Currently the Comparator is exposed in Region, STore and StoreFile. There is 
> another discussion whether to expose it at all layers or only at Region. 
> However since we are exposing this to CPs CellComparator being @Private is 
> not the ideal way to do it. We have to change it to LimitedPrivate. But 
> CellComparator has lot of additional methods which are internal (like where a 
> Cell is compared with an incoming byte[] used in index comparsions etc).
> One way to expose is that as being done now in HBASE-18826 - by exposing the 
> return type as Comparator. But this is not powerful. It only allows to 
> compare cells. So we try to expose an IA.LimitedPrivate interface that is 
> more powerful and allows comparing individual cell components also. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208561#comment-16208561
 ] 

Hudson commented on HBASE-19032:


FAILURE: Integrated in Jenkins build HBase-1.2-JDK7 #241 (See 
[https://builds.apache.org/job/HBase-1.2-JDK7/241/])
HBASE-19032 Set mimetype for patches uploaded by submit-patch.py (appy: rev 
6d03d25009d9fda2363fb5fe912fe43112336a65)
* (edit) dev-support/submit-patch.py


> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18946) Stochastic load balancer assigns replica regions to the same RS

[huaxiang sun (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208547#comment-16208547
 ] 

huaxiang sun commented on HBASE-18946:
--

Do we need to apply the same collection logic to EnableTableProcedure (to 
address the TODO in the comment)? Otherwise, +1.

> Stochastic load balancer assigns replica regions to the same RS
> ---
>
> Key: HBASE-18946
> URL: https://issues.apache.org/jira/browse/HBASE-18946
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0.0-alpha-3
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18946.patch, HBASE-18946.patch, 
> TestRegionReplicasWithRestartScenarios.java
>
>
> Trying out region replica and its assignment I can see that some times the 
> default LB Stocahstic load balancer assigns replica regions to the same RS. 
> This happens when we have 3 RS checked in and we have a table with 3 
> replicas. When a RS goes down then the replicas being assigned to same RS is 
> acceptable but the case when we have enough RS to assign this behaviour is 
> undesirable and does not solve the purpose of replicas. 
> [~huaxiang] and [~enis]. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208541#comment-16208541
 ] 

Hudson commented on HBASE-19032:


FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #309 (See 
[https://builds.apache.org/job/HBase-1.3-JDK7/309/])
HBASE-19032 Set mimetype for patches uploaded by submit-patch.py (appy: rev 
80c14c9b702d9910de4641ff22b478ccbb1cadfd)
* (edit) dev-support/submit-patch.py


> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208536#comment-16208536
 ] 

Hudson commented on HBASE-19032:


FAILURE: Integrated in Jenkins build HBase-1.3-JDK8 #324 (See 
[https://builds.apache.org/job/HBase-1.3-JDK8/324/])
HBASE-19032 Set mimetype for patches uploaded by submit-patch.py (appy: rev 
80c14c9b702d9910de4641ff22b478ccbb1cadfd)
* (edit) dev-support/submit-patch.py


> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Appy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Appy updated HBASE-19032:
-
Fix Version/s: 2.0.0-alpha-4

> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-18906) Investigate Phoenix usages of Region#waitForXXX APIs

[Andrew Purtell (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208529#comment-16208529
 ] 

Andrew Purtell edited comment on HBASE-18906 at 10/17/17 10:46 PM:
---

Maybe the misunderstanding we keep having is everyone is assuming I am a 
Phoenix developer coming here to provide Phoenix feedback. No. I am an HBase 
developer. I rarely touch Phoenix. I was involved with the first generation 
coprocessor APIs. That's it. If I've made a suggestion where Phoenix is doing 
something to my knowledge I've said it, otherwise I am not looking to defend 
against an adversarial questioning of what Phoenix might or might not be doing. 
I admit it's a bit unfair for me to bring this frustration to this issue where 
there is missing context, so I apologize for that. Anyway, it's fine to 
consider this resolved from my perspective... Do what you will, that is fine 
with me.


was (Author: apurtell):
Maybe the misunderstanding we keep having is everyone is assuming I am a 
Phoenix developer coming here to provide Phoenix feedback. No. I am an HBase 
developer. I rarely touch Phoenix. I was involved with the first generation 
coprocessor APIs. That's it. If I've made a suggestion where Phoenix is doing 
something to my knowledge I've said it, otherwise I am not looking to defend 
against an adversarial questioning of what Phoenix might or might not be doing. 

> Investigate Phoenix usages of Region#waitForXXX APIs
> 
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Appy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Appy resolved HBASE-19032.
--
Resolution: Fixed

> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Appy (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208531#comment-16208531
 ] 

Appy commented on HBASE-19032:
--

Committed to master and all the way back to branch-1.2.

> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (HBASE-18906) Investigate Phoenix usages of Region#waitForXXX APIs

[Andrew Purtell (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208529#comment-16208529
 ] 

Andrew Purtell edited comment on HBASE-18906 at 10/17/17 10:45 PM:
---

Maybe the misunderstanding we keep having is everyone is assuming I am a 
Phoenix developer coming here to provide Phoenix feedback. No. I am an HBase 
developer. I rarely touch Phoenix. I was involved with the first generation 
coprocessor APIs. That's it. If I've made a suggestion where Phoenix is doing 
something to my knowledge I've said it, otherwise I am not looking to defend 
against an adversarial questioning of what Phoenix might or might not be doing. 


was (Author: apurtell):
Maybe the misunderstanding we keep having is everyone is assuming I am a 
Phoenix developer coming here to provide Phoenix feedback. No. I am an HBase 
developer. I rarely touch Phoenix. I was involved with the first generation 
coprocessor APIs. That's it. 

> Investigate Phoenix usages of Region#waitForXXX APIs
> 
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18906) Investigate Phoenix usages of Region#waitForXXX APIs

[Andrew Purtell (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208529#comment-16208529
 ] 

Andrew Purtell commented on HBASE-18906:


Maybe the misunderstanding we keep having is everyone is assuming I am a 
Phoenix developer coming here to provide Phoenix feedback. No. I am an HBase 
developer. I rarely touch Phoenix. I was involved with the first generation 
coprocessor APIs. That's it. 

> Investigate Phoenix usages of Region#waitForXXX APIs
> 
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Appy (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208527#comment-16208527
 ] 

Appy commented on HBASE-19032:
--

Inception...uploaded patch using updated script. Click on it to verify.
Committing to master.

> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18906) Investigate Phoenix usages of Region#waitForXXX APIs

[Andrew Purtell (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208525#comment-16208525
 ] 

Andrew Purtell commented on HBASE-18906:


Maybe a shruggie would have been better. No desire to comment further.

> Investigate Phoenix usages of Region#waitForXXX APIs
> 
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Appy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Appy updated HBASE-19032:
-
Attachment: (was: )

> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Appy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Appy updated HBASE-19032:
-
Attachment: HBASE-19032.master.001.patch

> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Appy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Appy updated HBASE-19032:
-
Attachment: (was: HBASE-19032.master.002.patch)

> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-19032.master.001.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Appy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Appy updated HBASE-19032:
-
Attachment: HBASE-19032.master.002.patch

> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments:  u'/Users/appy/patches/HBASE-19032.master.001.patch', mode 'rb' at 
> 0x10c7bdf60>, HBASE-19032.master.002.patch
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Appy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-19032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Appy updated HBASE-19032:
-
Attachment: 

> Set Content-Type header for patches uploaded by submit-patch.py
> ---
>
> Key: HBASE-19032
> URL: https://issues.apache.org/jira/browse/HBASE-19032
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments:  u'/Users/appy/patches/HBASE-19032.master.001.patch', mode 'rb' at 0x10c7bdf60>
>
>
> The patches uploaded by submit-patch.py script get automatically downloaded 
> when clicked.
> Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18906) Investigate Phoenix usages of Region#waitForXXX APIs

[Josh Elser (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208518#comment-16208518
 ] 

Josh Elser commented on HBASE-18906:


bq. You guys all want to insist on having something to point to and otherwise 
don't care. So... ok? Whatever.

Wow, well, actually I just wanted to see if there was a use-case that we could 
pass to Anoop that, as a not-so-Phoenix-y developer, would server as a good 
example of what a "good API" looks like. If it's purely hypothetical, that's 
fine. I didn't mean for that to be a touchy question.

I understand and agree about how these would be generally useful APIs to have.

> Investigate Phoenix usages of Region#waitForXXX APIs
> 
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (HBASE-19032) Set Content-Type header for patches uploaded by submit-patch.py

[Appy (JIRA)]

Appy created HBASE-19032:


 Summary: Set Content-Type header for patches uploaded by 
submit-patch.py
 Key: HBASE-19032
 URL: https://issues.apache.org/jira/browse/HBASE-19032
 Project: HBase
  Issue Type: Bug
Reporter: Appy
Assignee: Appy


The patches uploaded by submit-patch.py script get automatically downloaded 
when clicked.
Quite annoying. Sometimes it's easier to see the patch in the browser itself.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18960) A few bug fixes and minor improvements around batchMutate()

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208512#comment-16208512
 ] 

Hudson commented on HBASE-18960:


FAILURE: Integrated in Jenkins build HBase-2.0 #705 (See 
[https://builds.apache.org/job/HBase-2.0/705/])
HBASE-18960 A few bug fixes and minor improvements around batchMutate (stack: 
rev 08dff49620adee39714fe8466c66a159489599be)
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionReplayEvents.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java


> A few bug fixes and minor improvements around batchMutate()
> ---
>
> Key: HBASE-18960
> URL: https://issues.apache.org/jira/browse/HBASE-18960
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0-alpha-3
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0-alpha-4
>
> Attachments: hbase-18960.master.001.patch, 
> hbase-18960.master.002.patch, hbase-18960.master.003.patch, 
> hbase-18960.master.004.patch, hbase-18960.master.005.patch, 
> hbase-18960.master.005.patch, hbase-18960.master.006.patch, 
> hbase-18960.master.007.patch, hbase-18960.master.008.patch, 
> hbase-18960.master.009.patch
>
>
> Batch validation and preparation can be done before we start iterating over 
> batch operations for writes. observedExceptions, familyCellMaps and 
> durability can be stored in BatchOperation as they are batch wide. For all 
> operations, done by preBatchMutate() CP hook, operation status needs to be 
> SUCCESS. Modify and use doWALAppend() from doMiniBatchMutate().



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18350) RSGroups are broken under AMv2

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208513#comment-16208513
 ] 

Hudson commented on HBASE-18350:


FAILURE: Integrated in Jenkins build HBase-2.0 #705 (See 
[https://builds.apache.org/job/HBase-2.0/705/])
HBASE-18350 RSGroups are broken under AMv2 (stack: rev 
6765f5e203d0930e6305c1ba9aa8762e80fcbc8e)
* (edit) 
hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupBasedLoadBalancer.java
* (edit) 
hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/rsgroup/TestRSGroupsOfflineMode.java
* (edit) 
hbase-rsgroup/src/test/java/org/apache/hadoop/hbase/rsgroup/TestRSGroups.java
* (edit) hbase-shell/src/main/ruby/shell/commands/get_rsgroup.rb
* (edit) hbase-server/src/main/resources/hbase-webapps/master/table.jsp
* (edit) hbase-shell/src/main/ruby/shell/commands/move_servers_rsgroup.rb
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/ProcedureSyncWait.java
* (edit) 
hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupAdminServer.java
* (edit) hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/master/assignment/AssignmentManager.java
* (edit) hbase-shell/src/main/ruby/hbase/rsgroup_admin.rb


> RSGroups are broken under AMv2
> --
>
> Key: HBASE-18350
> URL: https://issues.apache.org/jira/browse/HBASE-18350
> Project: HBase
>  Issue Type: Bug
>  Components: rsgroup
>Affects Versions: 2.0.0-alpha-1
>Reporter: Stephen Yuan Jiang
>Assignee: Balazs Meszaros
>Priority: Blocker
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18350.master.001.patch, 
> HBASE-18350.master.002.patch, HBASE-18350.master.003.patch, 
> HBASE-18350.master.004.patch, HBASE-18350.master.004.patch, 
> HBASE-18350.master.004.patch, HBASE-18350.master.005.patch, 
> HBASE-18350.master.006.patch, HBASE-18350.master.006.patch
>
>
> The following RSGroups tests were disabled by Core Proc-V2 AM in HBASE-14614:
> - Disabled/Ignore TestRSGroupsOfflineMode#testOffline; need to dig in on what 
> offline is.
> - Disabled/Ignore TestRSGroups.
> This JIRA tracks the work to enable them (or remove/modify if not applicable).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18984) [AMv2] Retain assignment does not work well in AMv2

[Ted Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208505#comment-16208505
 ] 

Ted Yu commented on HBASE-18984:


{code}
186 if (this.targetServer != null && !isServerOnline(env, 
targetServer)) {
187   LOG.info("Can not assign region to a dead target RegionServer:"
{code}
DEBUG logging should be enough.

> [AMv2] Retain assignment does not work well in AMv2
> ---
>
> Key: HBASE-18984
> URL: https://issues.apache.org/jira/browse/HBASE-18984
> Project: HBase
>  Issue Type: Bug
>  Components: proc-v2
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: HBASE-18984-V1-master.patch, Screen Shot 2017-10-10 at 
> 2.24.19 PM.png
>
>
> work on 8.17 Retain assignment in 
> https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.epjn9nege80k
> To reproduce this error, in hbase shell:
> createTable t1 --> list_regions 't1' --> disable 't1' ---> enable 't1' --> 
> list_reigons 't1' (maybe you need to try enable/disable multiple times)
> See attached images. same region assigned to different region servers



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18906) Investigate Phoenix usages of Region#waitForXXX APIs

[Andrew Purtell (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208506#comment-16208506
 ] 

Andrew Purtell commented on HBASE-18906:


bq. Do you have examples other Phoenix code snippets that could benefit from 
the other suggestions you made?

You guys all want to insist on having something to point to and otherwise don't 
care. So... ok? Whatever.

I've made suggestions I think will be helpful to coprocessor developers now and 
in the future. 

> Investigate Phoenix usages of Region#waitForXXX APIs
> 
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18906) Investigate Phoenix usages of Region#waitForXXX APIs

[Josh Elser (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208500#comment-16208500
 ] 

Josh Elser commented on HBASE-18906:


bq. With this the above code part req can be fulfilled?

Yup, that's my understanding!

[~apurtell], I know this one example is just 1/3 of the original API 
suggestions you outlined. Do you have examples other Phoenix code snippets that 
could benefit from the other suggestions you made? (or [~sergey.soldatov] too).

> Investigate Phoenix usages of Region#waitForXXX APIs
> 
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses 
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons.  This 
> issue is to see why they need them and whether alternate ways are possible. 
> This seems to be too much internal stuff and a normal CP hook calling these 
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in 
> issues (As said by Andy) we should suggest/fix for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19018) Use of hadoop internals that require bouncycastle should declare bouncycastle dependency

[Josh Elser (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208496#comment-16208496
 ] 

Josh Elser commented on HBASE-19018:


You still dealing with subsequent failures, [~busbey]? Need any help?

> Use of hadoop internals that require bouncycastle should declare bouncycastle 
> dependency
> 
>
> Key: HBASE-19018
> URL: https://issues.apache.org/jira/browse/HBASE-19018
> Project: HBase
>  Issue Type: Bug
>  Components: dependencies, test
>Affects Versions: 2.0.0-alpha-3
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
>
> The tests for HBASE-15806 rely on a Hadoop internal class, 
> {{KeyStoreTestUtil}}, which in turn relies on the Bouncycastle library for 
> certificate generation.
> when building / running with Hadoop 2.7.1, we accidentally get a bouncycastle 
> implementation via a transitive dependency of {{hadoop-minikdc}}. When 
> attempting to run against Hadoop 3.0.0-alpha4 and 3.0.0-beta1 (and presumably 
> future Hadoop 3.y releases), this bouncycastle jar is no longer pulled in and 
> we fail with a CNFE.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18984) [AMv2] Retain assignment does not work well in AMv2

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208495#comment-16208495
 ] 

Hadoop QA commented on HBASE-18984:
---

| (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}  2m 
44s{color} | {color:red} Docker failed to build yetus/hbase:5d60123. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-18984 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12892692/HBASE-18984-V1-master.patch
 |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/9168/console |
| Powered by | Apache Yetus 0.4.0   http://yetus.apache.org |


This message was automatically generated.



> [AMv2] Retain assignment does not work well in AMv2
> ---
>
> Key: HBASE-18984
> URL: https://issues.apache.org/jira/browse/HBASE-18984
> Project: HBase
>  Issue Type: Bug
>  Components: proc-v2
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: HBASE-18984-V1-master.patch, Screen Shot 2017-10-10 at 
> 2.24.19 PM.png
>
>
> work on 8.17 Retain assignment in 
> https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.epjn9nege80k
> To reproduce this error, in hbase shell:
> createTable t1 --> list_regions 't1' --> disable 't1' ---> enable 't1' --> 
> list_reigons 't1' (maybe you need to try enable/disable multiple times)
> See attached images. same region assigned to different region servers



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18984) [AMv2] Retain assignment does not work well in AMv2

[Yi Liang (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208493#comment-16208493
 ] 

Yi Liang commented on HBASE-18984:
--

Hi [~ram_krish], This patch only contains some clean up about region nodes 
status updated that maybe related to this jira.
Could you help to review, Thanks

 

> [AMv2] Retain assignment does not work well in AMv2
> ---
>
> Key: HBASE-18984
> URL: https://issues.apache.org/jira/browse/HBASE-18984
> Project: HBase
>  Issue Type: Bug
>  Components: proc-v2
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: HBASE-18984-V1-master.patch, Screen Shot 2017-10-10 at 
> 2.24.19 PM.png
>
>
> work on 8.17 Retain assignment in 
> https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.epjn9nege80k
> To reproduce this error, in hbase shell:
> createTable t1 --> list_regions 't1' --> disable 't1' ---> enable 't1' --> 
> list_reigons 't1' (maybe you need to try enable/disable multiple times)
> See attached images. same region assigned to different region servers



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18984) [AMv2] Retain assignment does not work well in AMv2

[Yi Liang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yi Liang updated HBASE-18984:
-
Attachment: HBASE-18984-V1-master.patch

> [AMv2] Retain assignment does not work well in AMv2
> ---
>
> Key: HBASE-18984
> URL: https://issues.apache.org/jira/browse/HBASE-18984
> Project: HBase
>  Issue Type: Bug
>  Components: proc-v2
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: HBASE-18984-V1-master.patch, Screen Shot 2017-10-10 at 
> 2.24.19 PM.png
>
>
> work on 8.17 Retain assignment in 
> https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.epjn9nege80k
> To reproduce this error, in hbase shell:
> createTable t1 --> list_regions 't1' --> disable 't1' ---> enable 't1' --> 
> list_reigons 't1' (maybe you need to try enable/disable multiple times)
> See attached images. same region assigned to different region servers



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18984) [AMv2] Retain assignment does not work well in AMv2

[Yi Liang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yi Liang updated HBASE-18984:
-
Status: Patch Available  (was: Open)

> [AMv2] Retain assignment does not work well in AMv2
> ---
>
> Key: HBASE-18984
> URL: https://issues.apache.org/jira/browse/HBASE-18984
> Project: HBase
>  Issue Type: Bug
>  Components: proc-v2
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: HBASE-18984-V1-master.patch, Screen Shot 2017-10-10 at 
> 2.24.19 PM.png
>
>
> work on 8.17 Retain assignment in 
> https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.epjn9nege80k
> To reproduce this error, in hbase shell:
> createTable t1 --> list_regions 't1' --> disable 't1' ---> enable 't1' --> 
> list_reigons 't1' (maybe you need to try enable/disable multiple times)
> See attached images. same region assigned to different region servers



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18990) ServerLoad doesn't override #equals which leads to #equals in ClusterStatus always false

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208483#comment-16208483
 ] 

Hudson commented on HBASE-18990:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3905 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/3905/])
HBASE-18990 ServerLoad doesn't override #equals which leads to #equals 
(chia7712: rev 9f61f8b281cea1f7eb299be386b7f74b70a2272f)
* (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/ServerLoad.java
* (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/ClusterStatus.java
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientClusterStatus.java


> ServerLoad doesn't override #equals which leads to #equals in ClusterStatus 
> always false
> 
>
> Key: HBASE-18990
> URL: https://issues.apache.org/jira/browse/HBASE-18990
> Project: HBase
>  Issue Type: Bug
>Reporter: Reid Chan
>Assignee: Reid Chan
>Priority: Trivial
> Fix For: 2.0.0
>
> Attachments: HBASE-18990.master.001.patch, 
> HBASE-18990.master.002.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18893) Remove Add/Modify/DeleteColumnFamilyProcedure in favor of using ModifyTableProcedure

[Mike Drob (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208480#comment-16208480
 ] 

Mike Drob commented on HBASE-18893:
---

Will need to update MasterObserver too, v2 of a patch coming soon.

> Remove Add/Modify/DeleteColumnFamilyProcedure in favor of using 
> ModifyTableProcedure
> 
>
> Key: HBASE-18893
> URL: https://issues.apache.org/jira/browse/HBASE-18893
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors, master
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18893.patch
>
>
> The shell changed from using separate add/modify/delete column calls to 
> funneling everything through modify table for performance reasons. We know 
> that using modify table works for everything. Let's drop the old code for 
> Add/Modify/Delete Column so that we have a lower maintenance burden and fewer 
> code paths to reason about.
>  Was: shell 'alter' command no longer distinguishes column 
> add/modify/delete
> After HBASE-15641 all 'alter' commands go through a single modifyTable call 
> at the end, so we no longer can easily distinguish add, modify, and delete 
> column events. This potentially affects coprocessors that needed the update 
> notifications for new or removed columns.
> Let's let the shell still make separate behaviour calls like it did before 
> without undoing the batching that seems pretty useful.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19007) Align Services Interfaces in Master and RegionServer

[Appy (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208472#comment-16208472
 ] 

Appy commented on HBASE-19007:
--

I think it's "reasonable" because although the method is ugly, we get two 
things:
- Completes the cleanup work of CP interfaces, have been long effort ...phew
- Cleanup of ugliness being introduced here will have no externality and hence 
can be done after alpha/beta/2.0.

> Align Services Interfaces in Master and RegionServer
> 
>
> Key: HBASE-19007
> URL: https://issues.apache.org/jira/browse/HBASE-19007
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Priority: Blocker
> Attachments: HBASE-19007.master.001.patch, 
> HBASE-19007.master.002.patch, HBASE-19007.master.003.patch
>
>
> HBASE-18183 adds a CoprocessorRegionServerService to give a view on 
> RegionServiceServices that is safe to expose to Coprocessors.
> On the Master-side, MasterServices becomes an Interface for exposing to 
> Coprocessors.
> We need to align the two.
> For background, see 
> https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (HBASE-18893) Remove Add/Modify/DeleteColumnFamilyProcedure in favor of using ModifyTableProcedure

[Mike Drob (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob reassigned HBASE-18893:
-

 Assignee: Mike Drob
  Summary: Remove Add/Modify/DeleteColumnFamilyProcedure in favor of 
using ModifyTableProcedure  (was: shell 'alter' command no longer distinguishes 
column add/modify/delete)
Fix Version/s: 2.0.0-alpha-4
  Description: 
The shell changed from using separate add/modify/delete column calls to 
funneling everything through modify table for performance reasons. We know that 
using modify table works for everything. Let's drop the old code for 
Add/Modify/Delete Column so that we have a lower maintenance burden and fewer 
code paths to reason about.


 Was: shell 'alter' command no longer distinguishes column 
add/modify/delete

After HBASE-15641 all 'alter' commands go through a single modifyTable call at 
the end, so we no longer can easily distinguish add, modify, and delete column 
events. This potentially affects coprocessors that needed the update 
notifications for new or removed columns.

Let's let the shell still make separate behaviour calls like it did before 
without undoing the batching that seems pretty useful.

  was:
After HBASE-15641 all 'alter' commands go through a single modifyTable call at 
the end, so we no longer can easily distinguish add, modify, and delete column 
events. This potentially affects coprocessors that needed the update 
notifications for new or removed columns.

Let's let the shell still make separate behaviour calls like it did before 
without undoing the batching that seems pretty useful.

  Component/s: (was: shell)
   master
   Coprocessors

Targeting for a4 and updating title since this impacts CPs.

bq. You'd remove AddCFP and DCFP in favor of what? A modifytable procedure?
Yep.

> Remove Add/Modify/DeleteColumnFamilyProcedure in favor of using 
> ModifyTableProcedure
> 
>
> Key: HBASE-18893
> URL: https://issues.apache.org/jira/browse/HBASE-18893
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors, master
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18893.patch
>
>
> The shell changed from using separate add/modify/delete column calls to 
> funneling everything through modify table for performance reasons. We know 
> that using modify table works for everything. Let's drop the old code for 
> Add/Modify/Delete Column so that we have a lower maintenance burden and fewer 
> code paths to reason about.
>  Was: shell 'alter' command no longer distinguishes column 
> add/modify/delete
> After HBASE-15641 all 'alter' commands go through a single modifyTable call 
> at the end, so we no longer can easily distinguish add, modify, and delete 
> column events. This potentially affects coprocessors that needed the update 
> notifications for new or removed columns.
> Let's let the shell still make separate behaviour calls like it did before 
> without undoing the batching that seems pretty useful.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-19007) Align Services Interfaces in Master and RegionServer

[Appy (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208463#comment-16208463
 ] 

Appy commented on HBASE-19007:
--

sounds reasonable way to move forward for now. 

> Align Services Interfaces in Master and RegionServer
> 
>
> Key: HBASE-19007
> URL: https://issues.apache.org/jira/browse/HBASE-19007
> Project: HBase
>  Issue Type: Task
>Reporter: stack
>Priority: Blocker
> Attachments: HBASE-19007.master.001.patch, 
> HBASE-19007.master.002.patch, HBASE-19007.master.003.patch
>
>
> HBASE-18183 adds a CoprocessorRegionServerService to give a view on 
> RegionServiceServices that is safe to expose to Coprocessors.
> On the Master-side, MasterServices becomes an Interface for exposing to 
> Coprocessors.
> We need to align the two.
> For background, see 
> https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18893) shell 'alter' command no longer distinguishes column add/modify/delete

[Mike Drob (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob updated HBASE-18893:
--
Attachment: HBASE-18893.patch

Proposed patch. Safe to delete tests since TestModifyTableProcedure already 
does these things.

> shell 'alter' command no longer distinguishes column add/modify/delete
> --
>
> Key: HBASE-18893
> URL: https://issues.apache.org/jira/browse/HBASE-18893
> Project: HBase
>  Issue Type: Bug
>  Components: shell
>Reporter: Mike Drob
> Attachments: HBASE-18893.patch
>
>
> After HBASE-15641 all 'alter' commands go through a single modifyTable call 
> at the end, so we no longer can easily distinguish add, modify, and delete 
> column events. This potentially affects coprocessors that needed the update 
> notifications for new or removed columns.
> Let's let the shell still make separate behaviour calls like it did before 
> without undoing the batching that seems pretty useful.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-18893) shell 'alter' command no longer distinguishes column add/modify/delete

[stack (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-18893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208457#comment-16208457
 ] 

stack commented on HBASE-18893:
---

bq. This potentially affects coprocessors that needed the update notifications 
for new or removed columns.

Just 'potentially' or is it actually?

Notion of bypass has to get a rework before alpha-4; default will be no bypass 
allowed.. just a few preXXX methods can bypass by returning true as result 
(TODO -- thats short version).

You'd remove AddCFP and DCFP in favor of what? A modifytable procedure?

Thanks [~mdrob].

> shell 'alter' command no longer distinguishes column add/modify/delete
> --
>
> Key: HBASE-18893
> URL: https://issues.apache.org/jira/browse/HBASE-18893
> Project: HBase
>  Issue Type: Bug
>  Components: shell
>Reporter: Mike Drob
>
> After HBASE-15641 all 'alter' commands go through a single modifyTable call 
> at the end, so we no longer can easily distinguish add, modify, and delete 
> column events. This potentially affects coprocessors that needed the update 
> notifications for new or removed columns.
> Let's let the shell still make separate behaviour calls like it did before 
> without undoing the batching that seems pretty useful.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (HBASE-14093) deduplicate copies of bootstrap files

[Mike Drob (JIRA)]

[ 
https://issues.apache.org/jira/browse/HBASE-14093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208459#comment-16208459
 ] 

Mike Drob commented on HBASE-14093:
---

+1 patch looks good to me from visual inspection, i will try apply and test it 
when i get a chance.

> deduplicate copies of bootstrap files
> -
>
> Key: HBASE-14093
> URL: https://issues.apache.org/jira/browse/HBASE-14093
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Sean Busbey
>Assignee: Tamas Penzes
>  Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-14093.master.001.patch, 
> HBASE-14093.master.002.patch, HBASE-14093.master.002.patch, 
> HBASE-14093.master.003.patch, HBASE-14093.master.003.patch, 
> HBASE-14093.master.004.patch, patch-shadedjars.txt
>
>
> right now we have a couple of different copies of the bootstrap js and css 
> files. It'll be easier to maintain them later if we can centralize.
> Move them to a common location and use maven to populate them as needed in 
> various component build directories.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (HBASE-18703) Inconsistent behavior for preBatchMutate in doMiniBatchMutate and processRowsWithLocks

[Mike Drob (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-18703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob updated HBASE-18703:
--
Fix Version/s: (was: 2.0.0-alpha-4)
   2.0.0-beta-1

> Inconsistent behavior for preBatchMutate in doMiniBatchMutate and 
> processRowsWithLocks
> --
>
> Key: HBASE-18703
> URL: https://issues.apache.org/jira/browse/HBASE-18703
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: Umesh Agashe
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: hbase-18703.master.001.patch, 
> hbase-18703.master.002.patch, hbase-18703.master.003.patch, 
> hbase-18703.master.004.patch, hbase-18703.master.005.patch, 
> hbase-18703.master.005.patch, hbase-18703.master.005.patch, 
> hbase-18703.master.006.patch, hbase-18703.master.007.patch
>
>
> In doMiniBatchMutate, the preBatchMutate is called before building WAL, but 
> in processRowsWithLocks, we suggest the RowProcessor implementation to build 
> WAL in process  method, which is ahead of preBatchMutate.
> If a CP modifies the mutations, especially if it removes some cells from the 
> mutations, then the behavior of processRowsWithLocks is broken. The changes 
> applied to memstore and WAL will be different. And there is no way to remove 
> entries from a WALEdit through CP. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)