[jira] [Commented] (HBASE-22514) Move rsgroup feature into core of HBase
[
https://issues.apache.org/jira/browse/HBASE-22514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889389#comment-16889389
]
Hudson commented on HBASE-22514:
Results for branch HBASE-22514
[build #20 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22514/20/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22514/20//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22514/20//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22514/20//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Move rsgroup feature into core of HBase
> ---
>
> Key: HBASE-22514
> URL: https://issues.apache.org/jira/browse/HBASE-22514
> Project: HBase
> Issue Type: Umbrella
> Components: Admin, Client, rsgroup
>Reporter: Yechao Chen
>Assignee: Duo Zhang
>Priority: Major
> Attachments: HBASE-22514.master.001.patch,
> image-2019-05-31-18-25-38-217.png
>
>
> The class RSGroupAdminClient is not public
> we need to use java api RSGroupAdminClient to manager RSG
> so RSGroupAdminClient should be public
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (HBASE-21426) TestEncryptionKeyRotation.testCFKeyRotation is flaky
[
https://issues.apache.org/jira/browse/HBASE-21426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889372#comment-16889372
]
Hudson commented on HBASE-21426:
Results for branch branch-2
[build #2090 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2090/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2090//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2090//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2090//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> TestEncryptionKeyRotation.testCFKeyRotation is flaky
>
>
> Key: HBASE-21426
> URL: https://issues.apache.org/jira/browse/HBASE-21426
> Project: HBase
> Issue Type: Bug
>Reporter: Xiaolin Ha
>Assignee: Xiaolin Ha
>Priority: Major
> Fix For: 3.0.0, 2.3.0, 2.2.1
>
> Attachments: testCFKeyRotation [Jenkins test result].pdf
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (HBASE-22673) Avoid to expose protobuf stuff in Hbck interface
[
https://issues.apache.org/jira/browse/HBASE-22673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889371#comment-16889371
]
Hudson commented on HBASE-22673:
Results for branch branch-2
[build #2090 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2090/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2090//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2090//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2090//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Avoid to expose protobuf stuff in Hbck interface
>
>
> Key: HBASE-22673
> URL: https://issues.apache.org/jira/browse/HBASE-22673
> Project: HBase
> Issue Type: Sub-task
> Components: hbck2
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Major
> Fix For: 3.0.0, 2.3.0, 2.2.1
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (HBASE-22622) WALKey Extended Attributes
[
https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889366#comment-16889366
]
Hudson commented on HBASE-22622:
Results for branch branch-2
[build #2091 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2091/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2091//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2091//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/2091//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> WALKey Extended Attributes
> --
>
> Key: HBASE-22622
> URL: https://issues.apache.org/jira/browse/HBASE-22622
> Project: HBase
> Issue Type: New Feature
> Components: wal
>Reporter: Geoffrey Jacoby
>Assignee: Geoffrey Jacoby
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
> Attachments: HBASE-22622-branch-1.patch, HBASE-22622-branch-2.patch,
> HBASE-22622.patch, HBASE-22622.v01.patch
>
>
> It would be useful if the WAL protobuf and WALKey class included an optional
> map of extended key/value attributes that downstream coprocessors could use
> to annotate WAL Entries. While standard HBase replication would not use them,
> custom replication endpoints could use the data to make filtering decisions
> or take actions.
> An example use case would be allowing a tool like Phoenix to annotate
> WAL.Entries to indicate that a given Entry is associated with a particular
> Phoenix view rather than the base Phoenix table. (Multiple logical views in
> Phoenix can map to the same physical HBase table.) A custom replication
> endpoint might choose to replicate some views but not others.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (HBASE-22622) WALKey Extended Attributes
[
https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889360#comment-16889360
]
Hudson commented on HBASE-22622:
Results for branch branch-1
[build #959 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/959/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/959//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/959//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/959//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> WALKey Extended Attributes
> --
>
> Key: HBASE-22622
> URL: https://issues.apache.org/jira/browse/HBASE-22622
> Project: HBase
> Issue Type: New Feature
> Components: wal
>Reporter: Geoffrey Jacoby
>Assignee: Geoffrey Jacoby
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
> Attachments: HBASE-22622-branch-1.patch, HBASE-22622-branch-2.patch,
> HBASE-22622.patch, HBASE-22622.v01.patch
>
>
> It would be useful if the WAL protobuf and WALKey class included an optional
> map of extended key/value attributes that downstream coprocessors could use
> to annotate WAL Entries. While standard HBase replication would not use them,
> custom replication endpoints could use the data to make filtering decisions
> or take actions.
> An example use case would be allowing a tool like Phoenix to annotate
> WAL.Entries to indicate that a given Entry is associated with a particular
> Phoenix view rather than the base Phoenix table. (Multiple logical views in
> Phoenix can map to the same physical HBase table.) A custom replication
> endpoint might choose to replicate some views but not others.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (HBASE-22622) WALKey Extended Attributes
[
https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889295#comment-16889295
]
HBase QA commented on HBASE-22622:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 2m
55s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
26s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
24s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 7m
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
48s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
24s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
12m 27s{color} | {color:green} Patch does not cause any errors with Hadoop
2.8.5 2.9.2 or 3.1.2. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
1m 35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 7m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
50s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
33s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
21s{color} | {color:green} hbase-protocol in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}252m 21s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
16s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}316m 35s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.client.TestSnapshotTemporaryDirectoryWithRegionReplicas |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=18.09.8 Server=18.09.8 base:
https://builds.apache.org/job/PreCommit-HBASE-Build/654/artifact/patchprocess/Dockerfile
|
| JIRA Issue | HBASE-22622 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/atta
[jira] [Commented] (HBASE-21426) TestEncryptionKeyRotation.testCFKeyRotation is flaky
[
https://issues.apache.org/jira/browse/HBASE-21426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889281#comment-16889281
]
Hudson commented on HBASE-21426:
Results for branch branch-2.2
[build #447 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/447/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/447//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/447//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/447//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> TestEncryptionKeyRotation.testCFKeyRotation is flaky
>
>
> Key: HBASE-21426
> URL: https://issues.apache.org/jira/browse/HBASE-21426
> Project: HBase
> Issue Type: Bug
>Reporter: Xiaolin Ha
>Assignee: Xiaolin Ha
>Priority: Major
> Fix For: 3.0.0, 2.3.0, 2.2.1
>
> Attachments: testCFKeyRotation [Jenkins test result].pdf
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (HBASE-22622) WALKey Extended Attributes
[ https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-22622: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) > WALKey Extended Attributes > -- > > Key: HBASE-22622 > URL: https://issues.apache.org/jira/browse/HBASE-22622 > Project: HBase > Issue Type: New Feature > Components: wal >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby >Priority: Major > Fix For: 3.0.0, 1.5.0, 2.3.0 > > Attachments: HBASE-22622-branch-1.patch, HBASE-22622-branch-2.patch, > HBASE-22622.patch, HBASE-22622.v01.patch > > > It would be useful if the WAL protobuf and WALKey class included an optional > map of extended key/value attributes that downstream coprocessors could use > to annotate WAL Entries. While standard HBase replication would not use them, > custom replication endpoints could use the data to make filtering decisions > or take actions. > An example use case would be allowing a tool like Phoenix to annotate > WAL.Entries to indicate that a given Entry is associated with a particular > Phoenix view rather than the base Phoenix table. (Multiple logical views in > Phoenix can map to the same physical HBase table.) A custom replication > endpoint might choose to replicate some views but not others. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [hbase] apurtell closed pull request #352: HBASE-22622 - WALKey Extended Attributes
apurtell closed pull request #352: HBASE-22622 - WALKey Extended Attributes URL: https://github.com/apache/hbase/pull/352 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (HBASE-22717) [HBCK2] Expose replication fixes from hbck1
[ https://issues.apache.org/jira/browse/HBASE-22717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-22717: -- Assignee: stack Fix Version/s: hbase-operator-tools-1.0.0 Release Note: Adds 'replication' command to HBCK2. Will clear old deleted peer queues and if a table name is passed, can clear replication barrier flags. Exposes the old hbck1 code that did this. Status: Patch Available (was: Open) Merged. > [HBCK2] Expose replication fixes from hbck1 > --- > > Key: HBASE-22717 > URL: https://issues.apache.org/jira/browse/HBASE-22717 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack >Priority: Major > Fix For: hbase-operator-tools-1.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [hbase-operator-tools] saintstack commented on issue #13: HBASE-22717 [HBCK2] Expose replication fixes from hbck1
saintstack commented on issue #13: HBASE-22717 [HBCK2] Expose replication fixes from hbck1 URL: https://github.com/apache/hbase-operator-tools/pull/13#issuecomment-513402684 Merged small change that exposes what used to be in place in hbck1. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [hbase-operator-tools] saintstack merged pull request #13: HBASE-22717 [HBCK2] Expose replication fixes from hbck1
saintstack merged pull request #13: HBASE-22717 [HBCK2] Expose replication fixes from hbck1 URL: https://github.com/apache/hbase-operator-tools/pull/13 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22622) WALKey Extended Attributes
[ https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889206#comment-16889206 ] Andrew Purtell commented on HBASE-22622: Attached what I plan to commit after tests finish > WALKey Extended Attributes > -- > > Key: HBASE-22622 > URL: https://issues.apache.org/jira/browse/HBASE-22622 > Project: HBase > Issue Type: New Feature > Components: wal >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby >Priority: Major > Fix For: 3.0.0, 1.5.0, 2.3.0 > > Attachments: HBASE-22622-branch-1.patch, HBASE-22622-branch-2.patch, > HBASE-22622.patch, HBASE-22622.v01.patch > > > It would be useful if the WAL protobuf and WALKey class included an optional > map of extended key/value attributes that downstream coprocessors could use > to annotate WAL Entries. While standard HBase replication would not use them, > custom replication endpoints could use the data to make filtering decisions > or take actions. > An example use case would be allowing a tool like Phoenix to annotate > WAL.Entries to indicate that a given Entry is associated with a particular > Phoenix view rather than the base Phoenix table. (Multiple logical views in > Phoenix can map to the same physical HBase table.) A custom replication > endpoint might choose to replicate some views but not others. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (HBASE-22622) WALKey Extended Attributes
[ https://issues.apache.org/jira/browse/HBASE-22622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-22622: --- Attachment: HBASE-22622.patch HBASE-22622-branch-2.patch HBASE-22622-branch-1.patch > WALKey Extended Attributes > -- > > Key: HBASE-22622 > URL: https://issues.apache.org/jira/browse/HBASE-22622 > Project: HBase > Issue Type: New Feature > Components: wal >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby >Priority: Major > Fix For: 3.0.0, 1.5.0, 2.3.0 > > Attachments: HBASE-22622-branch-1.patch, HBASE-22622-branch-2.patch, > HBASE-22622.patch, HBASE-22622.v01.patch > > > It would be useful if the WAL protobuf and WALKey class included an optional > map of extended key/value attributes that downstream coprocessors could use > to annotate WAL Entries. While standard HBase replication would not use them, > custom replication endpoints could use the data to make filtering decisions > or take actions. > An example use case would be allowing a tool like Phoenix to annotate > WAL.Entries to indicate that a given Entry is associated with a particular > Phoenix view rather than the base Phoenix table. (Multiple logical views in > Phoenix can map to the same physical HBase table.) A custom replication > endpoint might choose to replicate some views but not others. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [hbase] apurtell commented on a change in pull request #352: HBASE-22622 - WALKey Extended Attributes
apurtell commented on a change in pull request #352: HBASE-22622 - WALKey
Extended Attributes
URL: https://github.com/apache/hbase/pull/352#discussion_r305533271
##
File path:
hbase-server/src/main/java/org/apache/hadoop/hbase/wal/WALKeyImpl.java
##
@@ -573,6 +622,12 @@ public void readFieldsFromPb(WALProtos.WALKey walKey,
if (walKey.hasOrigSequenceNumber()) {
this.origLogSeqNum = walKey.getOrigSequenceNumber();
}
+if (walKey.getExtendedAttributesCount() > 0){
+ this.extendedAttributes = new
HashMap<>(walKey.getExtendedAttributesCount());
+ for (WALProtos.Attribute attr : walKey.getExtendedAttributesList()){
+extendedAttributes.put(attr.getKey(), attr.getValue().toByteArray());
Review comment:
Noticed while backporting. Attribute values may have been compressed and
need to be decompressed. Will fix up for commit.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [hbase-operator-tools] asf-ci commented on issue #13: HBASE-22717 [HBCK2] Expose replication fixes from hbck1
asf-ci commented on issue #13: HBASE-22717 [HBCK2] Expose replication fixes from hbck1 URL: https://github.com/apache/hbase-operator-tools/pull/13#issuecomment-513384206 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/PreCommit-HBASE-OPERATOR-TOOLS-Build/54/ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [hbase-operator-tools] asf-ci commented on issue #13: HBASE-22717 [HBCK2] Expose replication fixes from hbck1
asf-ci commented on issue #13: HBASE-22717 [HBCK2] Expose replication fixes from hbck1 URL: https://github.com/apache/hbase-operator-tools/pull/13#issuecomment-513378413 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/PreCommit-HBASE-OPERATOR-TOOLS-Build/53/ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [hbase-operator-tools] asf-ci commented on issue #13: HBASE-22717 [HBCK2] Expose replication fixes from hbck1
asf-ci commented on issue #13: HBASE-22717 [HBCK2] Expose replication fixes from hbck1 URL: https://github.com/apache/hbase-operator-tools/pull/13#issuecomment-513376713 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/PreCommit-HBASE-OPERATOR-TOOLS-Build/52/ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [hbase-operator-tools] asf-ci commented on issue #13: HBASE-22717 [HBCK2] Expose replication fixes from hbck1
asf-ci commented on issue #13: HBASE-22717 [HBCK2] Expose replication fixes from hbck1 URL: https://github.com/apache/hbase-operator-tools/pull/13#issuecomment-513373682 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/PreCommit-HBASE-OPERATOR-TOOLS-Build/51/ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [hbase-operator-tools] saintstack opened a new pull request #13: HBASE-22717 [HBCK2] Expose replication fixes from hbck1
saintstack opened a new pull request #13: HBASE-22717 [HBCK2] Expose replication fixes from hbck1 URL: https://github.com/apache/hbase-operator-tools/pull/13 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (HBASE-22717) [HBCK2] Expose replication fixes from hbck1
stack created HBASE-22717: - Summary: [HBCK2] Expose replication fixes from hbck1 Key: HBASE-22717 URL: https://issues.apache.org/jira/browse/HBASE-22717 Project: HBase Issue Type: Sub-task Reporter: stack -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (HBASE-21745) Make HBCK2 be able to fix issues other than region assignment
[ https://issues.apache.org/jira/browse/HBASE-21745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889132#comment-16889132 ] stack commented on HBASE-21745: --- Linking a good one by [~wchevreuil] > Make HBCK2 be able to fix issues other than region assignment > - > > Key: HBASE-21745 > URL: https://issues.apache.org/jira/browse/HBASE-21745 > Project: HBase > Issue Type: Umbrella > Components: hbase-operator-tools, hbck2 >Reporter: Duo Zhang >Assignee: stack >Priority: Critical > > This is what [~apurtell] posted on mailing-list, HBCK2 should support > * -Rebuild meta from region metadata in the filesystem, aka offline meta > rebuild.- > * -Fix assignment errors (undeployed regions, double assignments (yes, > should not be possible), etc)- (See > https://issues.apache.org/jira/browse/HBASE-21745?focusedCommentId=16888302&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16888302) > * Fix region holes, overlaps, and other errors in the region chain > * Fix failed split and merge transactions that have failed to roll back due > to some bug (related to previous) > * -Enumerate store files to determine file level corruption and sideline > corrupt files- > * -Fix hfile link problems (dangling / broken)- -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (HBASE-22707) [HBCK2] MasterRpcServices assigns method should try to reload regions from meta if the passed regions isn't found under AssignmentManager RegionsStateStore
[ https://issues.apache.org/jira/browse/HBASE-22707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889128#comment-16889128 ] stack commented on HBASE-22707: --- Interesting. We need something like this. I like that you hook it into assigns. I'm wary though of re-use of joinCluster. The messaging in logs will look strange. Will say stuff like 'Joining cluster...' and 'Waiting for RegionServers to join;'. Then we re-add chores, do the unnecessary wait on RS. Should we just add a method that gets the new row in hbase:meta and then does what loadMeta#visitRegionState call does? > [HBCK2] MasterRpcServices assigns method should try to reload regions from > meta if the passed regions isn't found under AssignmentManager > RegionsStateStore > --- > > Key: HBASE-22707 > URL: https://issues.apache.org/jira/browse/HBASE-22707 > Project: HBase > Issue Type: Task > Components: hbck2, master >Affects Versions: 2.2.0, 2.3.0, 2.1.5 >Reporter: Wellington Chevreuil >Assignee: Wellington Chevreuil >Priority: Major > Fix For: 2.3.0 > > Attachments: HBASE-22707.branch-2.001.patch > > > Although HBCK2 related, this is a master side improvement. On situations > where regions are missing in META, any online fix tool such as the one being > implemented in HBASE-22567 would require a further master restart to get > RegionsStateStore reloaded from META, so that master can be aware of the > newly re-added regions. > After regions are re-added to meta in CLOSED state, it should be possible to > bring those by simply invoking hbck2 _assigns_ command. But before > _MasterRpcServices.assigns_ submits an _Assign_ procedure, it validates first > if the given region is available on _AssignmentManager.RegionsStateStore_. > The current patch reloads meta on _MasterRpcServices.assigns_ if the given > region is not found on the first lookup, then try a new lookup again before > giving-up on region assignment. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [hbase] apurtell commented on issue #352: HBASE-22622 - WALKey Extended Attributes
apurtell commented on issue #352: HBASE-22622 - WALKey Extended Attributes URL: https://github.com/apache/hbase/pull/352#issuecomment-513336739 Test failures in latest precommit look environmental in nature. Will check locally before merging this. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-21745) Make HBCK2 be able to fix issues other than region assignment
[ https://issues.apache.org/jira/browse/HBASE-21745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889062#comment-16889062 ] stack commented on HBASE-21745: --- A few thoughts on remaining items: * Fix region holes, overlaps, and other errors in the region chain * Fix failed split and merge transactions that have failed to roll back due to some bug (related to previous) There are holes and overlaps in hbase:meta and then there are holes and overlaps in the filesystem (hdfs). In the past, hbck1 would fix 'holes and overlaps' in hdfs then hbase:meta would be consulted and adjusted to pick up the hdfs changes. Lets not do it this way for hbck2 (Caveat HBASE-22567 which finds hbase:meta holes and if an hdfs region, hoists it up into hbase;meta). In hbck2, perhaps the Master itself can see 'holes' and 'overlaps' in hbase:meta. Master already runs a process on a period to ‘check’ hbase:meta called CatalogJanitor. It could minimally report holes and overlaps (as well as unknown servers, etc.). I was going to have a look at doing this. CJ could report to the UI its findings (after the [~zghaobac] new tendency) What about leftover directories in hdfs? Orphans and broken regions or broken tables? In hdfs, hbck1 used to have the notion of 'adoption' where a new region was created in a target table and the 'orphan' region's content was copied into the new location. Thereafter, there'd be machinations to get the new region up into hbase:meta. What if we ran an 'adoption service' in the Master where hbck2 would pass the Master a list of directories and tell the Master to 'adopt' the content whether files or dropped regions, overlapping dirs, or even tables? The Master's hbase:meta would have to be healthy first so new data had a home to go to. On fix split and merge transactions, this category of issues we should roll up into the general master fix described above where something like CJ recognizes any problem (it already does a bunch of the heavy-lifting for split/merges). The 'HBASE-21965 Fix failed split and merge transactions that have failed to roll back' "fix" above has actually been undone for now in favor of "HBASE-22709 Add a web ui to show the failed splited/merged regions" whose intent is listing in UI split/merges with recipes for fix. And then perhaps a release of hbase-operator-tools? > Make HBCK2 be able to fix issues other than region assignment > - > > Key: HBASE-21745 > URL: https://issues.apache.org/jira/browse/HBASE-21745 > Project: HBase > Issue Type: Umbrella > Components: hbase-operator-tools, hbck2 >Reporter: Duo Zhang >Assignee: stack >Priority: Critical > > This is what [~apurtell] posted on mailing-list, HBCK2 should support > * -Rebuild meta from region metadata in the filesystem, aka offline meta > rebuild.- > * -Fix assignment errors (undeployed regions, double assignments (yes, > should not be possible), etc)- (See > https://issues.apache.org/jira/browse/HBASE-21745?focusedCommentId=16888302&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16888302) > * Fix region holes, overlaps, and other errors in the region chain > * Fix failed split and merge transactions that have failed to roll back due > to some bug (related to previous) > * -Enumerate store files to determine file level corruption and sideline > corrupt files- > * -Fix hfile link problems (dangling / broken)- -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (HBASE-21477) [documentation] doc against an hbase2 client connecting to an hbase1 cluster
[ https://issues.apache.org/jira/browse/HBASE-21477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889021#comment-16889021 ] stack commented on HBASE-21477: --- [~guertsen] it doesn't work is why... a hbase2 can't talk to an hbase1. We should be explicit in our doc about it sir. > [documentation] doc against an hbase2 client connecting to an hbase1 cluster > > > Key: HBASE-21477 > URL: https://issues.apache.org/jira/browse/HBASE-21477 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: stack >Priority: Major > > Currently nothing in the refguide that doing this is a bad idea > (https://stackoverflow.com/questions/46468430/hbase-client-2-0-x-error). > Should at least say don't do it if only to quote when folks try. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (HBASE-21477) [documentation] doc against an hbase2 client connecting to an hbase1 cluster
[ https://issues.apache.org/jira/browse/HBASE-21477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16889010#comment-16889010 ] Timofei Guertsen commented on HBASE-21477: -- Hi Michael, Could you, please, clarify why this is a bad idea (even if we don't intend to use the Admin API in our hbase2 client application)? Thank you, Timofei > [documentation] doc against an hbase2 client connecting to an hbase1 cluster > > > Key: HBASE-21477 > URL: https://issues.apache.org/jira/browse/HBASE-21477 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: stack >Priority: Major > > Currently nothing in the refguide that doing this is a bad idea > (https://stackoverflow.com/questions/46468430/hbase-client-2-0-x-error). > Should at least say don't do it if only to quote when folks try. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (HBASE-22716) upgrade zookeeper version to 3.5.5
[ https://issues.apache.org/jira/browse/HBASE-22716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16888968#comment-16888968 ] stack commented on HBASE-22716: --- What are the differences between the two versions? Can a 3.5.5 client talk to a 3.4.x ensemble do you know? Where would we commit it? Could we cut down the spew of logging that zk does on hbase startup I wonder (follow-on issue). Thanks. > upgrade zookeeper version to 3.5.5 > -- > > Key: HBASE-22716 > URL: https://issues.apache.org/jira/browse/HBASE-22716 > Project: HBase > Issue Type: Improvement > Components: Zookeeper >Reporter: maoling >Assignee: maoling >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (HBASE-21879) Read HFile's block to ByteBuffer directly instead of to byte for reducing young gc purpose
[
https://issues.apache.org/jira/browse/HBASE-21879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1694#comment-1694
]
ramkrishna.s.vasudevan commented on HBASE-21879:
OOO for personal reasons. No access to official emails during this period.
> Read HFile's block to ByteBuffer directly instead of to byte for reducing
> young gc purpose
> --
>
> Key: HBASE-21879
> URL: https://issues.apache.org/jira/browse/HBASE-21879
> Project: HBase
> Issue Type: Improvement
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-21879.v1.patch, HBASE-21879.v1.patch,
> QPS-latencies-before-HBASE-21879.png, gc-data-before-HBASE-21879.png
>
>
> In HFileBlock#readBlockDataInternal, we have the following:
> {code}
> @VisibleForTesting
> protected HFileBlock readBlockDataInternal(FSDataInputStream is, long offset,
> long onDiskSizeWithHeaderL, boolean pread, boolean verifyChecksum,
> boolean updateMetrics)
> throws IOException {
> // .
> // TODO: Make this ByteBuffer-based. Will make it easier to go to HDFS with
> BBPool (offheap).
> byte [] onDiskBlock = new byte[onDiskSizeWithHeader + hdrSize];
> int nextBlockOnDiskSize = readAtOffset(is, onDiskBlock, preReadHeaderSize,
> onDiskSizeWithHeader - preReadHeaderSize, true, offset +
> preReadHeaderSize, pread);
> if (headerBuf != null) {
> // ...
> }
> // ...
> }
> {code}
> In the read path, we still read the block from hfile to on-heap byte[], then
> copy the on-heap byte[] to offheap bucket cache asynchronously, and in my
> 100% get performance test, I also observed some frequent young gc, The
> largest memory footprint in the young gen should be the on-heap block byte[].
> In fact, we can read HFile's block to ByteBuffer directly instead of to
> byte[] for reducing young gc purpose. we did not implement this before,
> because no ByteBuffer reading interface in the older HDFS client, but 2.7+
> has supported this now, so we can fix this now. I think.
> Will provide an patch and some perf-comparison for this.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (HBASE-21879) Read HFile's block to ByteBuffer directly instead of to byte for reducing young gc purpose
[
https://issues.apache.org/jira/browse/HBASE-21879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1693#comment-1693
]
Hudson commented on HBASE-21879:
Results for branch HBASE-21879
[build #182 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/182/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/182//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/182//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/182//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Read HFile's block to ByteBuffer directly instead of to byte for reducing
> young gc purpose
> --
>
> Key: HBASE-21879
> URL: https://issues.apache.org/jira/browse/HBASE-21879
> Project: HBase
> Issue Type: Improvement
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-21879.v1.patch, HBASE-21879.v1.patch,
> QPS-latencies-before-HBASE-21879.png, gc-data-before-HBASE-21879.png
>
>
> In HFileBlock#readBlockDataInternal, we have the following:
> {code}
> @VisibleForTesting
> protected HFileBlock readBlockDataInternal(FSDataInputStream is, long offset,
> long onDiskSizeWithHeaderL, boolean pread, boolean verifyChecksum,
> boolean updateMetrics)
> throws IOException {
> // .
> // TODO: Make this ByteBuffer-based. Will make it easier to go to HDFS with
> BBPool (offheap).
> byte [] onDiskBlock = new byte[onDiskSizeWithHeader + hdrSize];
> int nextBlockOnDiskSize = readAtOffset(is, onDiskBlock, preReadHeaderSize,
> onDiskSizeWithHeader - preReadHeaderSize, true, offset +
> preReadHeaderSize, pread);
> if (headerBuf != null) {
> // ...
> }
> // ...
> }
> {code}
> In the read path, we still read the block from hfile to on-heap byte[], then
> copy the on-heap byte[] to offheap bucket cache asynchronously, and in my
> 100% get performance test, I also observed some frequent young gc, The
> largest memory footprint in the young gen should be the on-heap block byte[].
> In fact, we can read HFile's block to ByteBuffer directly instead of to
> byte[] for reducing young gc purpose. we did not implement this before,
> because no ByteBuffer reading interface in the older HDFS client, but 2.7+
> has supported this now, so we can fix this now. I think.
> Will provide an patch and some perf-comparison for this.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (HBASE-22673) Avoid to expose protobuf stuff in Hbck interface
[
https://issues.apache.org/jira/browse/HBASE-22673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1627#comment-1627
]
Hudson commented on HBASE-22673:
Results for branch master
[build #1243 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/1243/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/1243//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/1243//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/1243//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Avoid to expose protobuf stuff in Hbck interface
>
>
> Key: HBASE-22673
> URL: https://issues.apache.org/jira/browse/HBASE-22673
> Project: HBase
> Issue Type: Sub-task
> Components: hbck2
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Major
> Fix For: 3.0.0, 2.3.0, 2.2.1
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (HBASE-22514) Move rsgroup feature into core of HBase
[
https://issues.apache.org/jira/browse/HBASE-22514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16888761#comment-16888761
]
Hudson commented on HBASE-22514:
Results for branch HBASE-22514
[build #19 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22514/19/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22514/19//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22514/19//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22514/19//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Move rsgroup feature into core of HBase
> ---
>
> Key: HBASE-22514
> URL: https://issues.apache.org/jira/browse/HBASE-22514
> Project: HBase
> Issue Type: Umbrella
> Components: Admin, Client, rsgroup
>Reporter: Yechao Chen
>Assignee: Duo Zhang
>Priority: Major
> Attachments: HBASE-22514.master.001.patch,
> image-2019-05-31-18-25-38-217.png
>
>
> The class RSGroupAdminClient is not public
> we need to use java api RSGroupAdminClient to manager RSG
> so RSGroupAdminClient should be public
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [hbase] maoling opened a new pull request #394: HBASE-22716:upgrade zookeeper version to 3.5.5
maoling opened a new pull request #394: HBASE-22716:upgrade zookeeper version to 3.5.5 URL: https://github.com/apache/hbase/pull/394 - This zookeeper [3.5.5](http://zookeeper.apache.org/releases.html) release is a stable one and recommended for production use, which has no compatibility issues for the native java client api which hbase used. - Let's listen to the QA report before reviewing. - more details in the [HBASE-22716](https://issues.apache.org/jira/browse/HBASE-22716) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22673) Avoid to expose protobuf stuff in Hbck interface
[
https://issues.apache.org/jira/browse/HBASE-22673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16888735#comment-16888735
]
Hudson commented on HBASE-22673:
Results for branch branch-2.1
[build #1383 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(x) {color:red}-1 client integration test{color}
--Failed when running client tests on top of Hadoop 2. [see log for
details|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383//artifact/output-integration/hadoop-2.log].
(note that this means we didn't run on Hadoop 3)
> Avoid to expose protobuf stuff in Hbck interface
>
>
> Key: HBASE-22673
> URL: https://issues.apache.org/jira/browse/HBASE-22673
> Project: HBase
> Issue Type: Sub-task
> Components: hbck2
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Major
> Fix For: 3.0.0, 2.3.0, 2.2.1
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (HBASE-22527) [hbck2] Add a master web ui to show the problematic regions
[
https://issues.apache.org/jira/browse/HBASE-22527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16888734#comment-16888734
]
Hudson commented on HBASE-22527:
Results for branch branch-2.1
[build #1383 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(x) {color:red}-1 client integration test{color}
--Failed when running client tests on top of Hadoop 2. [see log for
details|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383//artifact/output-integration/hadoop-2.log].
(note that this means we didn't run on Hadoop 3)
> [hbck2] Add a master web ui to show the problematic regions
> ---
>
> Key: HBASE-22527
> URL: https://issues.apache.org/jira/browse/HBASE-22527
> Project: HBase
> Issue Type: Sub-task
> Components: hbase-operator-tools, hbck2
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Major
> Attachments: HBASE-22527.branch-2.0.001.patch,
> HBASE-22527.branch-2.1.001.patch, HBASE-22527.branch-2.1.002.patch,
> HBASE-22527.branch-2.1.003.patch, HBASE-22527.master.001.patch,
> HBASE-22527.master.002.patch, HBASE-22527.master.003.patch,
> HBASE-22527.master.004.patch, HBASE-22527.master.addendum.patch
>
>
> On our cluster which based 2.2.0, we found one problem: there are some opened
> regions which had wrong regionserver in meta. The regionserver is not exist.
> We used hbck2 to fix them by the following steps.
> # disable table
> # bypass the stucked close region procedure (as the target regionserver is
> not exist) and disable table procedure.
> # setRegionState to CLOSED.
> # setTableState to DISABLED.
> # enable table
> We found this problem by scan the hbase:meta. I thought we should add this
> feature to hbck2. The we can use hbck2 to find this problem. Thanks.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (HBASE-22537) Split happened Replica region can not be deleted after deleting table successfully and restarting RegionServer
[
https://issues.apache.org/jira/browse/HBASE-22537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16888733#comment-16888733
]
Hudson commented on HBASE-22537:
Results for branch branch-2.1
[build #1383 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(x) {color:red}-1 client integration test{color}
--Failed when running client tests on top of Hadoop 2. [see log for
details|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1383//artifact/output-integration/hadoop-2.log].
(note that this means we didn't run on Hadoop 3)
> Split happened Replica region can not be deleted after deleting table
> successfully and restarting RegionServer
> --
>
> Key: HBASE-22537
> URL: https://issues.apache.org/jira/browse/HBASE-22537
> Project: HBase
> Issue Type: Bug
> Components: Region Assignment
>Affects Versions: 2.1.1
>Reporter: Y. SREENIVASULU REDDY
>Assignee: Y. SREENIVASULU REDDY
>Priority: Minor
> Fix For: 2.1.6
>
> Attachments: HBASE-22537.002.patch, HBASE-22537.branch-2.1.002.patch,
> HBASE-22537.branch-2.1.003.patch, HBASE-22537.branch-2.1.004.patch,
> HBASE-22537.branch-2.1.005.patch, HBASE-22537.branch-2.1.patch,
> HBASE-22537.branch-2.patch, HBASE-22537.patch
>
>
> [Test step]
> 1.create a table (set RegionReplication=2).
> 2.insert data to the table utill region be splitted.
> 3.Disable and Drop the table.
> 4.Parent replica region holding Regionserver, Kill forcefully
> 5.HBase WebUI will show that the replica regions will be in RIT.
> [Expect Output]
> Parent replica region should be deleted.
> [Actual Output]
> Parent replica region still exists.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (HBASE-22695) Store the rsgroup of a table in table configuration
[ https://issues.apache.org/jira/browse/HBASE-22695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16888706#comment-16888706 ] Duo Zhang commented on HBASE-22695: --- This will be huge change. I think we need to define the behavior first. In the old implementation, changing the rsgroup of a table will lead to a move, but changing the rsgroup config of a namespace will not. In general, I prefer we do not trigger a move when doing this first, including changing the server set of a rsgroup. Let's do this asynchronously. The only exception is changing the rsgroup config of a table, where we need to reopen the regions of a table. Later we could see if we can provide a synchronous way, maybe we can return a proc id to client to let them query the status, just like what we have done for create table, etc. > Store the rsgroup of a table in table configuration > --- > > Key: HBASE-22695 > URL: https://issues.apache.org/jira/browse/HBASE-22695 > Project: HBase > Issue Type: Sub-task > Components: rsgroup >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (HBASE-22715) Use scan queues/executors for scans, when RWQueueRpcExecutor used
[ https://issues.apache.org/jira/browse/HBASE-22715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeongdae Kim updated HBASE-22715: - Description: When we use RWQueueRpcExecutor, all scans should be handled by scan handler threads, not read handler. Before HBASE-17508, when calling openScanner() in client, a region server doesn't make results, just open scanner and return scanner id. So, this request(open) is executed in read handlers intentionally. However, since HBASE-17508,, actual scan behavior happened while opening a scanner, I think this request should probably be executed in scan handlers when using RWQueueRpcExecutor. was: When we use RWQueueRpcExecutor, all scans should be handled by scan handler threads, not read handler. https://issues.apache.org/jira/browse/HBASE-17508 Before this patch, when calling openScanner() in client, a region server doesn't make results, just open scanner and return scanner id. So, this request(open) is executed in read handlers intentionally. However, since the patch, actual scan behavior happened while opening a scanner, I think this request should probably be executed in scan handlers when using RWQueueRpcExecutor. > Use scan queues/executors for scans, when RWQueueRpcExecutor used > - > > Key: HBASE-22715 > URL: https://issues.apache.org/jira/browse/HBASE-22715 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.10 >Reporter: Jeongdae Kim >Assignee: Jeongdae Kim >Priority: Minor > > When we use RWQueueRpcExecutor, all scans should be handled by scan handler > threads, not read handler. > > Before HBASE-17508, when calling openScanner() in client, a region server > doesn't make results, just open scanner and return scanner id. So, this > request(open) is executed in read handlers intentionally. > > However, since HBASE-17508,, actual scan behavior happened while opening a > scanner, > I think this request should probably be executed in scan handlers when using > RWQueueRpcExecutor. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (HBASE-22716) upgrade zookeeper version to 3.5.5
maoling created HBASE-22716: --- Summary: upgrade zookeeper version to 3.5.5 Key: HBASE-22716 URL: https://issues.apache.org/jira/browse/HBASE-22716 Project: HBase Issue Type: Improvement Components: Zookeeper Reporter: maoling Assignee: maoling -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [hbase] JeongDaeKim opened a new pull request #393: HBASE-22715 Use scan queues/executors for scans, when RWQueueRpcExecutor used
JeongDaeKim opened a new pull request #393: HBASE-22715 Use scan queues/executors for scans, when RWQueueRpcExecutor used URL: https://github.com/apache/hbase/pull/393 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (HBASE-22715) Use scan queues/executors for scans, when RWQueueRpcExecutor used
Jeongdae Kim created HBASE-22715: Summary: Use scan queues/executors for scans, when RWQueueRpcExecutor used Key: HBASE-22715 URL: https://issues.apache.org/jira/browse/HBASE-22715 Project: HBase Issue Type: Bug Affects Versions: 1.4.10 Reporter: Jeongdae Kim Assignee: Jeongdae Kim When we use RWQueueRpcExecutor, all scans should be handled by scan handler threads, not read handler. https://issues.apache.org/jira/browse/HBASE-17508 Before this patch, when calling openScanner() in client, a region server doesn't make results, just open scanner and return scanner id. So, this request(open) is executed in read handlers intentionally. However, since the patch, actual scan behavior happened while opening a scanner, I think this request should probably be executed in scan handlers when using RWQueueRpcExecutor. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
