[GitHub] [hbase] Apache-HBase commented on issue #120: HBASE-20494 Updated the version of metrics-core to 3.2.6
Apache-HBase commented on issue #120: HBASE-20494 Updated the version of metrics-core to 3.2.6 URL: https://github.com/apache/hbase/pull/120#issuecomment-487258045 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | 0 | reexec | 23 | Docker mode activated. | ||| _ Prechecks _ | | +1 | @author | 0 | The patch does not contain any @author tags. | | -0 | test4tests | 0 | 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. | ||| _ master Compile Tests _ | | +1 | mvninstall | 252 | master passed | | +1 | compile | 160 | master passed | | +1 | shadedjars | 266 | branch has no errors when building our shaded downstream artifacts. | | +1 | javadoc | 166 | master passed | ||| _ Patch Compile Tests _ | | +1 | mvninstall | 242 | the patch passed | | +1 | compile | 164 | the patch passed | | +1 | javac | 164 | the patch passed | | +1 | whitespace | 0 | The patch has no whitespace issues. | | +1 | xml | 2 | The patch has no ill-formed XML file. | | +1 | shadedjars | 264 | patch has no errors when building our shaded downstream artifacts. | | +1 | hadoopcheck | 494 | Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0. | | +1 | javadoc | 160 | the patch passed | ||| _ Other Tests _ | | -1 | unit | 10705 | root in the patch failed. | | +1 | asflicense | 38 | The patch does not generate ASF License warnings. | | | | 12991 | | | Reason | Tests | |---:|:--| | Failed junit tests | hadoop.hbase.replication.TestVerifyReplicationCrossDiffHdfs | | | hadoop.hbase.snapshot.TestExportSnapshotNoCluster | | Subsystem | Report/Notes | |--:|:-| | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-120/8/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/120 | | Optional Tests | dupname asflicense javac javadoc unit shadedjars hadoopcheck xml compile | | uname | Linux 9c2b3bdf7995 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | master / 962585d376 | | maven | version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) | | Default Java | 1.8.0_181 | | unit | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-120/8/artifact/out/patch-unit-root.txt | | Test Results | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-120/8/testReport/ | | Max. process+thread count | 5019 (vs. ulimit of 1) | | modules | C: . U: . | | Console output | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-120/8/console | | Powered by | Apache Yetus 0.9.0 http://yetus.apache.org | This message was automatically generated. 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-16217) Identify calling user in ObserverContext
[
https://issues.apache.org/jira/browse/HBASE-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827456#comment-16827456
]
Hudson commented on HBASE-16217:
Results for branch branch-1.4
[build #768 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/768/]:
(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.4/768//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.4/768//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.4/768//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Identify calling user in ObserverContext
>
>
> Key: HBASE-16217
> URL: https://issues.apache.org/jira/browse/HBASE-16217
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors, security
>Reporter: Gary Helmling
>Assignee: Gary Helmling
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-16217.branch-1.001.patch,
> HBASE-16217.master.001.patch, HBASE-16217.master.002.patch,
> HBASE-16217.master.003.patch
>
>
> We already either explicitly pass down the relevant User instance initiating
> an action through the call path, or it is available through
> RpcServer.getRequestUser(). We should carry this through in the
> ObserverContext for coprocessor upcalls and make use of it for permissions
> checking.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22310) checkAndMutate used an incorrect row to check the condition
[
https://issues.apache.org/jira/browse/HBASE-22310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827457#comment-16827457
]
Hudson commented on HBASE-22310:
Results for branch branch-1.4
[build #768 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/768/]:
(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.4/768//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.4/768//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.4/768//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> checkAndMutate used an incorrect row to check the condition
> ---
>
> Key: HBASE-22310
> URL: https://issues.apache.org/jira/browse/HBASE-22310
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.3.3, 1.4.9
>Reporter: Adonis Ling
>Assignee: Adonis Ling
>Priority: Major
> Fix For: 1.5.0, 1.4.10, 1.3.4
>
> Attachments: HBASE-22310-branch-1.patch,
> HBASE-22310.branch-1.3.001.patch, HBASE-22310.branch-1.3.002.patch,
> HBASE-22310.branch-1.4.001.patch, HBASE-22310.branch-1.4.002.patch,
> HBASE-22310.branch-1.4.003.patch
>
>
> In branch-1.4, checkAndMutate used the row of RowMutation to check the
> condition which is incorrect. It will fail in the case which is checking a
> row and mutate a different row.
> The issue doesn't happen in the master branch.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-17884) Backport HBASE-16217 to branch-1
[
https://issues.apache.org/jira/browse/HBASE-17884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827455#comment-16827455
]
Hudson commented on HBASE-17884:
Results for branch branch-1.4
[build #768 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/768/]:
(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.4/768//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.4/768//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.4/768//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Backport HBASE-16217 to branch-1
>
>
> Key: HBASE-17884
> URL: https://issues.apache.org/jira/browse/HBASE-17884
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors, security
>Reporter: Gary Helmling
>Assignee: Gary Helmling
>Priority: Major
> Fix For: 1.5.0
>
> Attachments: HBASE-17884-branch-1.patch, HBASE-17884-branch-1.patch,
> HBASE-17884.branch-1.001.patch
>
>
> The change to add calling user to ObserverContext in HBASE-16217 should also
> be applied to branch-1 to avoid use of UserGroupInformation.doAs() for access
> control checks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22310) checkAndMutate used an incorrect row to check the condition
[
https://issues.apache.org/jira/browse/HBASE-22310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827452#comment-16827452
]
Hudson commented on HBASE-22310:
Results for branch branch-1
[build #794 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/794/]:
(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/794//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/794//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/794//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> checkAndMutate used an incorrect row to check the condition
> ---
>
> Key: HBASE-22310
> URL: https://issues.apache.org/jira/browse/HBASE-22310
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.3.3, 1.4.9
>Reporter: Adonis Ling
>Assignee: Adonis Ling
>Priority: Major
> Fix For: 1.5.0, 1.4.10, 1.3.4
>
> Attachments: HBASE-22310-branch-1.patch,
> HBASE-22310.branch-1.3.001.patch, HBASE-22310.branch-1.3.002.patch,
> HBASE-22310.branch-1.4.001.patch, HBASE-22310.branch-1.4.002.patch,
> HBASE-22310.branch-1.4.003.patch
>
>
> In branch-1.4, checkAndMutate used the row of RowMutation to check the
> condition which is incorrect. It will fail in the case which is checking a
> row and mutate a different row.
> The issue doesn't happen in the master branch.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22081) master shutdown: close RpcServer and procWAL first thing
[
https://issues.apache.org/jira/browse/HBASE-22081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827439#comment-16827439
]
HBase QA commented on HBASE-22081:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
26s{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: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} 0m
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
14s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
20s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
51s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
14s{color} | {color:red} hbase-server: The patch generated 1 new + 283
unchanged - 0 fixed = 284 total (was 283) {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
20s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 4s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}135m 8s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
27s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}173m 43s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.coprocessor.TestMasterCoprocessorExceptionWithAbort |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base:
https://builds.apache.org/job/PreCommit-HBASE-Build/205/artifact/patchprocess/Dockerfile
|
| JIRA Issue | HBASE-22081 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12967205/HBASE-22081.01.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 839bd0029510 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 962585d376 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.11 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/205/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/205/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test
[jira] [Commented] (HBASE-22280) Separate read/write handler for priority request(especially for meta).
[
https://issues.apache.org/jira/browse/HBASE-22280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827431#comment-16827431
]
HBase QA commented on HBASE-22280:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 2m
34s{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:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} 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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
28s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 2m
43s{color} | {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
14s{color} | {color:red} hbase-server: The patch generated 1 new + 6 unchanged
- 0 fixed = 7 total (was 6) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} shadedjars {color} | {color:red} 3m
35s{color} | {color:red} patch has 11 errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m
3s{color} | {color:red} The patch causes 11 errors with Hadoop v2.7.4. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 4m
8s{color} | {color:red} The patch causes 11 errors with Hadoop v3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 54s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
9s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 35m 40s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base:
https://builds.apache.org/job/PreCommit-HBASE-Build/206/artifact/patchprocess/Dockerfile
|
| JIRA Issue | HBASE-22280 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12967208/HBASE-22280.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux f5768449a939 4.4.0-131-generic #157~14.04.1-Ubuntu SMP Fri Jul
13 08:53:17 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 962585d376 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.11 |
| mvninstall |
[jira] [Commented] (HBASE-22301) Consider rolling the WAL if the HDFS write pipeline is slow
[
https://issues.apache.org/jira/browse/HBASE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827428#comment-16827428
]
HBase QA commented on HBASE-22301:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 14m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
1s{color} | {color:blue} Findbugs executables are not available. {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 2 new or modified test
files. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
46s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
58s{color} | {color:green} branch-1 passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
5s{color} | {color:green} branch-1 passed with JDK v1.7.0_222 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
46s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
48s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
50s{color} | {color:green} branch-1 passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
1s{color} | {color:green} branch-1 passed with JDK v1.7.0_222 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
59s{color} | {color:green} the patch passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
5s{color} | {color:green} the patch passed with JDK v1.7.0_222 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s{color} | {color:green} The patch passed checkstyle in hbase-hadoop-compat
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s{color} | {color:green} The patch passed checkstyle in hbase-hadoop2-compat
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
23s{color} | {color:green} hbase-server: The patch generated 0 new + 94
unchanged - 6 fixed = 94 total (was 100) {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} 2m
54s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
1m 43s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
48s{color} | {color:green} the patch passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
1s{color} | {color:green} the patch passed with JDK v1.7.0_222 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
22s{color} | {color:green} hbase-hadoop-compat in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
28s{color} | {color:green} hbase-hadoop2-compat
[jira] [Commented] (HBASE-22301) Consider rolling the WAL if the HDFS write pipeline is slow
[
https://issues.apache.org/jira/browse/HBASE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827426#comment-16827426
]
David Manning commented on HBASE-22301:
---
{quote}Because I always want to check this and update the related metric if we
hit this condition. The other conditions can be exclusive with respect to each
other.
{quote}
It will now be theoretically possible for {{checkLogRoll}} to call
{{requestLogRoll}} twice in a row. If this is acceptable, then sounds good to
me. I couldn't immediately tell whether this would really roll twice or would
coalesce into one WAL roll.
+1 from me, thank you for the fix!
> Consider rolling the WAL if the HDFS write pipeline is slow
> ---
>
> Key: HBASE-22301
> URL: https://issues.apache.org/jira/browse/HBASE-22301
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
> Attachments: HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch,
> HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch,
> HBASE-22301-branch-1.patch
>
>
> Consider the case when a subset of the HDFS fleet is unhealthy but suffering
> a gray failure not an outright outage. HDFS operations, notably syncs, are
> abnormally slow on pipelines which include this subset of hosts. If the
> regionserver's WAL is backed by an impacted pipeline, all WAL handlers can be
> consumed waiting for acks from the datanodes in the pipeline (recall that
> some of them are sick). Imagine a write heavy application distributing load
> uniformly over the cluster at a fairly high rate. With the WAL subsystem
> slowed by HDFS level issues, all handlers can be blocked waiting to append to
> the WAL. Once all handlers are blocked, the application will experience
> backpressure. All (HBase) clients eventually have too many outstanding writes
> and block.
> Because the application is distributing writes near uniformly in the
> keyspace, the probability any given service endpoint will dispatch a request
> to an impacted regionserver, even a single regionserver, approaches 1.0. So
> the probability that all service endpoints will be affected approaches 1.0.
> In order to break the logjam, we need to remove the slow datanodes. Although
> there is HDFS level monitoring, mechanisms, and procedures for this, we
> should also attempt to take mitigating action at the HBase layer as soon as
> we find ourselves in trouble. It would be enough to remove the affected
> datanodes from the writer pipelines. A super simple strategy that can be
> effective is described below:
> This is with branch-1 code. I think branch-2's async WAL can mitigate but
> still can be susceptible. branch-2 sync WAL is susceptible.
> We already roll the WAL writer if the pipeline suffers the failure of a
> datanode and the replication factor on the pipeline is too low. We should
> also consider how much time it took for the write pipeline to complete a sync
> the last time we measured it, or the max over the interval from now to the
> last time we checked. If the sync time exceeds a configured threshold, roll
> the log writer then too. Fortunately we don't need to know which datanode is
> making the WAL write pipeline slow, only that syncs on the pipeline are too
> slow and exceeding a threshold. This is enough information to know when to
> roll it. Once we roll it, we will get three new randomly selected datanodes.
> On most clusters the probability the new pipeline includes the slow datanode
> will be low. (And if for some reason it does end up with a problematic
> datanode again, we roll again.)
> This is not a silver bullet but this can be a reasonably effective mitigation.
> Provide a metric for tracking when log roll is requested (and for what
> reason).
> Emit a log line at log roll time that includes datanode pipeline details for
> further debugging and analysis, similar to the existing slow FSHLog sync log
> line.
> If we roll too many times within a short interval of time this probably means
> there is a widespread problem with the fleet and so our mitigation is not
> helping and may be exacerbating those problems or operator difficulties.
> Ensure log roll requests triggered by this new feature happen infrequently
> enough to not cause difficulties under either normal or abnormal conditions.
> A very simple strategy that could work well under both normal and abnormal
> conditions is to define a fairly lengthy interval, default 5 minutes, and
> then insure we do not roll more than once during this interval for this
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22280) Separate read/write handler for priority request(especially for meta).
[ https://issues.apache.org/jira/browse/HBASE-22280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] binlijin updated HBASE-22280: - Status: Patch Available (was: Open) > Separate read/write handler for priority request(especially for meta). > -- > > Key: HBASE-22280 > URL: https://issues.apache.org/jira/browse/HBASE-22280 > Project: HBase > Issue Type: New Feature >Reporter: binlijin >Assignee: binlijin >Priority: Major > Attachments: HBASE-22280.patch > > > Client may give too many read pressure on meta, so blocking master write meta > for region open. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22280) Separate read/write handler for priority request(especially for meta).
[ https://issues.apache.org/jira/browse/HBASE-22280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] binlijin updated HBASE-22280: - Attachment: HBASE-22280.patch > Separate read/write handler for priority request(especially for meta). > -- > > Key: HBASE-22280 > URL: https://issues.apache.org/jira/browse/HBASE-22280 > Project: HBase > Issue Type: New Feature >Reporter: binlijin >Assignee: binlijin >Priority: Major > Attachments: HBASE-22280.patch > > > Client may give too many read pressure on meta, so blocking master write meta > for region open. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HBASE-22280) Separate read/write handler for priority request(especially for meta).
[ https://issues.apache.org/jira/browse/HBASE-22280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] binlijin reassigned HBASE-22280: Assignee: binlijin > Separate read/write handler for priority request(especially for meta). > -- > > Key: HBASE-22280 > URL: https://issues.apache.org/jira/browse/HBASE-22280 > Project: HBase > Issue Type: New Feature >Reporter: binlijin >Assignee: binlijin >Priority: Major > > Client may give too many read pressure on meta, so blocking master write meta > for region open. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase] busbey commented on issue #145: HBASE-7003 Moved backup examples into hbase-examples
busbey commented on issue #145: HBASE-7003 Moved backup examples into hbase-examples URL: https://github.com/apache/hbase/pull/145#issuecomment-487247074 I thought one of the consensus points for getting the backup/restore stuff into master was that it would be isolated in the one module. Maybe I'm misremembering though? 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-22081) master shutdown: close RpcServer and procWAL first thing
[ https://issues.apache.org/jira/browse/HBASE-22081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827407#comment-16827407 ] Sergey Shelukhin commented on HBASE-22081: -- Before the patch, it is mere coincidence that while all the other stuff is shutting down, the rpc that caused it has a chance to return. Caller could get unlucky and stop RPC would fail because RPC server was closed... now that we shut down RPC server first thing, it happens almost all the time. Added a small sleep before starting shutdown if it was triggered by and RPC request 0_o Unfortunately it doesn't seem to be possible externally to wait for RPC(s) responses to finish. > master shutdown: close RpcServer and procWAL first thing > > > Key: HBASE-22081 > URL: https://issues.apache.org/jira/browse/HBASE-22081 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Major > Attachments: HBASE-22081.01.patch, HBASE-22081.patch > > > I had a master get stuck due to HBASE-22079 and noticed it was logging RS > abort messages during shutdown. > [~bahramch] found some issues where messages are processed by old master > during shutdown due to a race condition in RS cache (or it could also happen > due to a network race). > Previously I found some bug where SCP was created during master shutdown that > had incorrect state (because some structures already got cleaned). > I think before master fencing is implemented we can at least make these > issues much less likely by thinking about shutdown order. > 1) First kill RCP server so we don't receive any more messages. There's no > need to receive messages when we are shutting down. Server heartbeats could > be impacted I guess, but I don't think they will be cause we currently only > kill RS on ZK timeout. > 2) Then do whatever cleanup we think is needed that requires proc wal. > 3) Then close proc WAL so no errant threads can create more procs. > 4) Then do whatever other cleanup. > 5) Finally delete znode. > Right now znode is deleted somewhat early I think, and RpcServer is closed > very late. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22081) master shutdown: close RpcServer and procWAL first thing
[ https://issues.apache.org/jira/browse/HBASE-22081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-22081: - Attachment: HBASE-22081.01.patch > master shutdown: close RpcServer and procWAL first thing > > > Key: HBASE-22081 > URL: https://issues.apache.org/jira/browse/HBASE-22081 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Major > Attachments: HBASE-22081.01.patch, HBASE-22081.patch > > > I had a master get stuck due to HBASE-22079 and noticed it was logging RS > abort messages during shutdown. > [~bahramch] found some issues where messages are processed by old master > during shutdown due to a race condition in RS cache (or it could also happen > due to a network race). > Previously I found some bug where SCP was created during master shutdown that > had incorrect state (because some structures already got cleaned). > I think before master fencing is implemented we can at least make these > issues much less likely by thinking about shutdown order. > 1) First kill RCP server so we don't receive any more messages. There's no > need to receive messages when we are shutting down. Server heartbeats could > be impacted I guess, but I don't think they will be cause we currently only > kill RS on ZK timeout. > 2) Then do whatever cleanup we think is needed that requires proc wal. > 3) Then close proc WAL so no errant threads can create more procs. > 4) Then do whatever other cleanup. > 5) Finally delete znode. > Right now znode is deleted somewhat early I think, and RpcServer is closed > very late. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-14789) Enhance the current spark-hbase connector
[ https://issues.apache.org/jira/browse/HBASE-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-14789: -- Labels: spark (was: ) > Enhance the current spark-hbase connector > - > > Key: HBASE-14789 > URL: https://issues.apache.org/jira/browse/HBASE-14789 > Project: HBase > Issue Type: Improvement > Components: hbase-connectors, spark >Reporter: Zhan Zhang >Assignee: Zhan Zhang >Priority: Major > Labels: spark > Fix For: 3.0.0, connector-1.0.0 > > Attachments: shc.pdf > > > This JIRA is to optimize the RDD construction in the current connector > implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22321) Add 1.5 release line to the Hadoop supported versions table
[
https://issues.apache.org/jira/browse/HBASE-22321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827401#comment-16827401
]
HBase QA commented on HBASE-22321:
--
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
22s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 12m
55s{color} | {color:blue} branch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
4s{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:blue}0{color} | {color:blue} refguide {color} | {color:blue} 7m
50s{color} | {color:blue} patch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
12s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 30m 7s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base:
https://builds.apache.org/job/PreCommit-HBASE-Build/203/artifact/patchprocess/Dockerfile
|
| JIRA Issue | HBASE-22321 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12967193/HBASE-22321.patch |
| Optional Tests | dupname asflicense refguide |
| uname | Linux 3d3248c90a10 4.4.0-143-generic #169~14.04.2-Ubuntu SMP Wed Feb
13 15:00:41 UTC 2019 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | master / 962585d376 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| refguide |
https://builds.apache.org/job/PreCommit-HBASE-Build/203/artifact/patchprocess/branch-site/book.html
|
| refguide |
https://builds.apache.org/job/PreCommit-HBASE-Build/203/artifact/patchprocess/patch-site/book.html
|
| Max. process+thread count | 62 (vs. ulimit of 1) |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/203/console |
| Powered by | Apache Yetus 0.9.0 http://yetus.apache.org |
This message was automatically generated.
> Add 1.5 release line to the Hadoop supported versions table
> ---
>
> Key: HBASE-22321
> URL: https://issues.apache.org/jira/browse/HBASE-22321
> Project: HBase
> Issue Type: Task
> Components: documentation
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 1.5.0
>
> Attachments: HBASE-22321.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22301) Consider rolling the WAL if the HDFS write pipeline is slow
[
https://issues.apache.org/jira/browse/HBASE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827398#comment-16827398
]
Andrew Purtell commented on HBASE-22301:
Updated patch, here is the change:
{code:java}
diff --git
a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java
b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java
index 24a2271564..b562946671 100644
---
a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java
+++
b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java
@@ -734,6 +734,8 @@ public class FSHLog implements WAL {
// NewPath could be equal to oldPath if replaceWriter fails.
newPath = replaceWriter(oldPath, newPath, nextWriter, nextHdfsOut);
tellListenersAboutPostLogRoll(oldPath, newPath);
+ // We got a new writer, so reset the slow sync count
+ slowSyncCount.set(0);
// Can we delete any of the old log files?
if (getNumRolledLogFiles() > 0) {
cleanOldLogs();
{code}
Seemed better to me to reset the count after we switched the writer, and it was
a bug actually that we didn't. Thanks for the catch [~dmanning]
> Consider rolling the WAL if the HDFS write pipeline is slow
> ---
>
> Key: HBASE-22301
> URL: https://issues.apache.org/jira/browse/HBASE-22301
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
> Attachments: HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch,
> HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch,
> HBASE-22301-branch-1.patch
>
>
> Consider the case when a subset of the HDFS fleet is unhealthy but suffering
> a gray failure not an outright outage. HDFS operations, notably syncs, are
> abnormally slow on pipelines which include this subset of hosts. If the
> regionserver's WAL is backed by an impacted pipeline, all WAL handlers can be
> consumed waiting for acks from the datanodes in the pipeline (recall that
> some of them are sick). Imagine a write heavy application distributing load
> uniformly over the cluster at a fairly high rate. With the WAL subsystem
> slowed by HDFS level issues, all handlers can be blocked waiting to append to
> the WAL. Once all handlers are blocked, the application will experience
> backpressure. All (HBase) clients eventually have too many outstanding writes
> and block.
> Because the application is distributing writes near uniformly in the
> keyspace, the probability any given service endpoint will dispatch a request
> to an impacted regionserver, even a single regionserver, approaches 1.0. So
> the probability that all service endpoints will be affected approaches 1.0.
> In order to break the logjam, we need to remove the slow datanodes. Although
> there is HDFS level monitoring, mechanisms, and procedures for this, we
> should also attempt to take mitigating action at the HBase layer as soon as
> we find ourselves in trouble. It would be enough to remove the affected
> datanodes from the writer pipelines. A super simple strategy that can be
> effective is described below:
> This is with branch-1 code. I think branch-2's async WAL can mitigate but
> still can be susceptible. branch-2 sync WAL is susceptible.
> We already roll the WAL writer if the pipeline suffers the failure of a
> datanode and the replication factor on the pipeline is too low. We should
> also consider how much time it took for the write pipeline to complete a sync
> the last time we measured it, or the max over the interval from now to the
> last time we checked. If the sync time exceeds a configured threshold, roll
> the log writer then too. Fortunately we don't need to know which datanode is
> making the WAL write pipeline slow, only that syncs on the pipeline are too
> slow and exceeding a threshold. This is enough information to know when to
> roll it. Once we roll it, we will get three new randomly selected datanodes.
> On most clusters the probability the new pipeline includes the slow datanode
> will be low. (And if for some reason it does end up with a problematic
> datanode again, we roll again.)
> This is not a silver bullet but this can be a reasonably effective mitigation.
> Provide a metric for tracking when log roll is requested (and for what
> reason).
> Emit a log line at log roll time that includes datanode pipeline details for
> further debugging and analysis, similar to the existing slow FSHLog sync log
> line.
> If we roll too many times within a short interval of time this probably means
> there is a widespread problem with the fleet and so our mitigation is
[jira] [Updated] (HBASE-22301) Consider rolling the WAL if the HDFS write pipeline is slow
[ https://issues.apache.org/jira/browse/HBASE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-22301: --- Attachment: HBASE-22301-branch-1.patch > Consider rolling the WAL if the HDFS write pipeline is slow > --- > > Key: HBASE-22301 > URL: https://issues.apache.org/jira/browse/HBASE-22301 > Project: HBase > Issue Type: Improvement > Components: wal >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 3.0.0, 1.5.0, 2.3.0 > > Attachments: HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch, > HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch, > HBASE-22301-branch-1.patch > > > Consider the case when a subset of the HDFS fleet is unhealthy but suffering > a gray failure not an outright outage. HDFS operations, notably syncs, are > abnormally slow on pipelines which include this subset of hosts. If the > regionserver's WAL is backed by an impacted pipeline, all WAL handlers can be > consumed waiting for acks from the datanodes in the pipeline (recall that > some of them are sick). Imagine a write heavy application distributing load > uniformly over the cluster at a fairly high rate. With the WAL subsystem > slowed by HDFS level issues, all handlers can be blocked waiting to append to > the WAL. Once all handlers are blocked, the application will experience > backpressure. All (HBase) clients eventually have too many outstanding writes > and block. > Because the application is distributing writes near uniformly in the > keyspace, the probability any given service endpoint will dispatch a request > to an impacted regionserver, even a single regionserver, approaches 1.0. So > the probability that all service endpoints will be affected approaches 1.0. > In order to break the logjam, we need to remove the slow datanodes. Although > there is HDFS level monitoring, mechanisms, and procedures for this, we > should also attempt to take mitigating action at the HBase layer as soon as > we find ourselves in trouble. It would be enough to remove the affected > datanodes from the writer pipelines. A super simple strategy that can be > effective is described below: > This is with branch-1 code. I think branch-2's async WAL can mitigate but > still can be susceptible. branch-2 sync WAL is susceptible. > We already roll the WAL writer if the pipeline suffers the failure of a > datanode and the replication factor on the pipeline is too low. We should > also consider how much time it took for the write pipeline to complete a sync > the last time we measured it, or the max over the interval from now to the > last time we checked. If the sync time exceeds a configured threshold, roll > the log writer then too. Fortunately we don't need to know which datanode is > making the WAL write pipeline slow, only that syncs on the pipeline are too > slow and exceeding a threshold. This is enough information to know when to > roll it. Once we roll it, we will get three new randomly selected datanodes. > On most clusters the probability the new pipeline includes the slow datanode > will be low. (And if for some reason it does end up with a problematic > datanode again, we roll again.) > This is not a silver bullet but this can be a reasonably effective mitigation. > Provide a metric for tracking when log roll is requested (and for what > reason). > Emit a log line at log roll time that includes datanode pipeline details for > further debugging and analysis, similar to the existing slow FSHLog sync log > line. > If we roll too many times within a short interval of time this probably means > there is a widespread problem with the fleet and so our mitigation is not > helping and may be exacerbating those problems or operator difficulties. > Ensure log roll requests triggered by this new feature happen infrequently > enough to not cause difficulties under either normal or abnormal conditions. > A very simple strategy that could work well under both normal and abnormal > conditions is to define a fairly lengthy interval, default 5 minutes, and > then insure we do not roll more than once during this interval for this > reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22301) Consider rolling the WAL if the HDFS write pipeline is slow
[
https://issues.apache.org/jira/browse/HBASE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827394#comment-16827394
]
Andrew Purtell commented on HBASE-22301:
{quote}nit: why not else if checkSlowSync in {{checkLogRoll}}:
{quote}
Because I always want to check this and update the related metric if we hit
this condition. The other conditions can be exclusive with respect to each
other.
{quote}it seems like {{slowSyncCount.set(0);}} should also be called in
requestLogRoll() since we're going to get a new WAL pipeline at that point
{quote}
Sure, new patch in just a sec.
> Consider rolling the WAL if the HDFS write pipeline is slow
> ---
>
> Key: HBASE-22301
> URL: https://issues.apache.org/jira/browse/HBASE-22301
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
> Attachments: HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch,
> HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch
>
>
> Consider the case when a subset of the HDFS fleet is unhealthy but suffering
> a gray failure not an outright outage. HDFS operations, notably syncs, are
> abnormally slow on pipelines which include this subset of hosts. If the
> regionserver's WAL is backed by an impacted pipeline, all WAL handlers can be
> consumed waiting for acks from the datanodes in the pipeline (recall that
> some of them are sick). Imagine a write heavy application distributing load
> uniformly over the cluster at a fairly high rate. With the WAL subsystem
> slowed by HDFS level issues, all handlers can be blocked waiting to append to
> the WAL. Once all handlers are blocked, the application will experience
> backpressure. All (HBase) clients eventually have too many outstanding writes
> and block.
> Because the application is distributing writes near uniformly in the
> keyspace, the probability any given service endpoint will dispatch a request
> to an impacted regionserver, even a single regionserver, approaches 1.0. So
> the probability that all service endpoints will be affected approaches 1.0.
> In order to break the logjam, we need to remove the slow datanodes. Although
> there is HDFS level monitoring, mechanisms, and procedures for this, we
> should also attempt to take mitigating action at the HBase layer as soon as
> we find ourselves in trouble. It would be enough to remove the affected
> datanodes from the writer pipelines. A super simple strategy that can be
> effective is described below:
> This is with branch-1 code. I think branch-2's async WAL can mitigate but
> still can be susceptible. branch-2 sync WAL is susceptible.
> We already roll the WAL writer if the pipeline suffers the failure of a
> datanode and the replication factor on the pipeline is too low. We should
> also consider how much time it took for the write pipeline to complete a sync
> the last time we measured it, or the max over the interval from now to the
> last time we checked. If the sync time exceeds a configured threshold, roll
> the log writer then too. Fortunately we don't need to know which datanode is
> making the WAL write pipeline slow, only that syncs on the pipeline are too
> slow and exceeding a threshold. This is enough information to know when to
> roll it. Once we roll it, we will get three new randomly selected datanodes.
> On most clusters the probability the new pipeline includes the slow datanode
> will be low. (And if for some reason it does end up with a problematic
> datanode again, we roll again.)
> This is not a silver bullet but this can be a reasonably effective mitigation.
> Provide a metric for tracking when log roll is requested (and for what
> reason).
> Emit a log line at log roll time that includes datanode pipeline details for
> further debugging and analysis, similar to the existing slow FSHLog sync log
> line.
> If we roll too many times within a short interval of time this probably means
> there is a widespread problem with the fleet and so our mitigation is not
> helping and may be exacerbating those problems or operator difficulties.
> Ensure log roll requests triggered by this new feature happen infrequently
> enough to not cause difficulties under either normal or abnormal conditions.
> A very simple strategy that could work well under both normal and abnormal
> conditions is to define a fairly lengthy interval, default 5 minutes, and
> then insure we do not roll more than once during this interval for this
> reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22301) Consider rolling the WAL if the HDFS write pipeline is slow
[
https://issues.apache.org/jira/browse/HBASE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827391#comment-16827391
]
David Manning commented on HBASE-22301:
---
+1 for current patch, but 2 comments below.
nit: why not else if checkSlowSync in {{checkLogRoll}}:
{code:java}
if (checkSlowSync()) {
{code}
Also, it seems like {{slowSyncCount.set(0);}} should also be called in
requestLogRoll() since we're going to get a new WAL pipeline at that point. If
we had enough slow syncs during the interval, but then we rolled the WAL for an
unrelated reason before the end of the interval, then we will roll again once
the interval is up given the current code.
Both comments are to try and limit extraneous roll requests, but seem unlikely
to cause any major issues.
> Consider rolling the WAL if the HDFS write pipeline is slow
> ---
>
> Key: HBASE-22301
> URL: https://issues.apache.org/jira/browse/HBASE-22301
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
> Attachments: HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch,
> HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch
>
>
> Consider the case when a subset of the HDFS fleet is unhealthy but suffering
> a gray failure not an outright outage. HDFS operations, notably syncs, are
> abnormally slow on pipelines which include this subset of hosts. If the
> regionserver's WAL is backed by an impacted pipeline, all WAL handlers can be
> consumed waiting for acks from the datanodes in the pipeline (recall that
> some of them are sick). Imagine a write heavy application distributing load
> uniformly over the cluster at a fairly high rate. With the WAL subsystem
> slowed by HDFS level issues, all handlers can be blocked waiting to append to
> the WAL. Once all handlers are blocked, the application will experience
> backpressure. All (HBase) clients eventually have too many outstanding writes
> and block.
> Because the application is distributing writes near uniformly in the
> keyspace, the probability any given service endpoint will dispatch a request
> to an impacted regionserver, even a single regionserver, approaches 1.0. So
> the probability that all service endpoints will be affected approaches 1.0.
> In order to break the logjam, we need to remove the slow datanodes. Although
> there is HDFS level monitoring, mechanisms, and procedures for this, we
> should also attempt to take mitigating action at the HBase layer as soon as
> we find ourselves in trouble. It would be enough to remove the affected
> datanodes from the writer pipelines. A super simple strategy that can be
> effective is described below:
> This is with branch-1 code. I think branch-2's async WAL can mitigate but
> still can be susceptible. branch-2 sync WAL is susceptible.
> We already roll the WAL writer if the pipeline suffers the failure of a
> datanode and the replication factor on the pipeline is too low. We should
> also consider how much time it took for the write pipeline to complete a sync
> the last time we measured it, or the max over the interval from now to the
> last time we checked. If the sync time exceeds a configured threshold, roll
> the log writer then too. Fortunately we don't need to know which datanode is
> making the WAL write pipeline slow, only that syncs on the pipeline are too
> slow and exceeding a threshold. This is enough information to know when to
> roll it. Once we roll it, we will get three new randomly selected datanodes.
> On most clusters the probability the new pipeline includes the slow datanode
> will be low. (And if for some reason it does end up with a problematic
> datanode again, we roll again.)
> This is not a silver bullet but this can be a reasonably effective mitigation.
> Provide a metric for tracking when log roll is requested (and for what
> reason).
> Emit a log line at log roll time that includes datanode pipeline details for
> further debugging and analysis, similar to the existing slow FSHLog sync log
> line.
> If we roll too many times within a short interval of time this probably means
> there is a widespread problem with the fleet and so our mitigation is not
> helping and may be exacerbating those problems or operator difficulties.
> Ensure log roll requests triggered by this new feature happen infrequently
> enough to not cause difficulties under either normal or abnormal conditions.
> A very simple strategy that could work well under both normal and abnormal
> conditions is to define a fairly lengthy interval, default 5 minutes, and
> then insure we do not roll more than once during this interval for this
> reason.
--
[jira] [Created] (HBASE-22321) Add 1.5 release line to the Hadoop supported versions table
Andrew Purtell created HBASE-22321: -- Summary: Add 1.5 release line to the Hadoop supported versions table Key: HBASE-22321 URL: https://issues.apache.org/jira/browse/HBASE-22321 Project: HBase Issue Type: Task Components: documentation Reporter: Andrew Purtell Assignee: Andrew Purtell Fix For: 1.5.0 Attachments: HBASE-22321.patch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22321) Add 1.5 release line to the Hadoop supported versions table
[ https://issues.apache.org/jira/browse/HBASE-22321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-22321: --- Status: Patch Available (was: Open) Hadoop support for 1.5 should be the same as 1.4. > Add 1.5 release line to the Hadoop supported versions table > --- > > Key: HBASE-22321 > URL: https://issues.apache.org/jira/browse/HBASE-22321 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 1.5.0 > > Attachments: HBASE-22321.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-16488) Starting namespace and quota services in master startup asynchronously
[ https://issues.apache.org/jira/browse/HBASE-16488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Cang updated HBASE-16488: Release Note: Provide an option to start namespace service in asynchronized manner without blocking master startup. This can avoid master initialization failed due to namespace table region takes long time to assign (eg. sometimes split log takes long time or hanging; or sometimes RS is temporarily not available; sometimes due to some unknown assignment issue). > Starting namespace and quota services in master startup asynchronously > -- > > Key: HBASE-16488 > URL: https://issues.apache.org/jira/browse/HBASE-16488 > Project: HBase > Issue Type: Improvement > Components: master >Affects Versions: 1.3.0, 1.0.3, 1.4.0, 1.1.5, 1.2.2, 2.0.0 >Reporter: Stephen Yuan Jiang >Assignee: Xu Cang >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-16488.branch-1.012.patch, > HBASE-16488.branch-1.012.patch, HBASE-16488.branch-1.013.patch, > HBASE-16488.branch-1.013.patch, HBASE-16488.branch-1.014.patch, > HBASE-16488.branch-1.015.patch, HBASE-16488.branch-1.016.patch, > HBASE-16488.branch-1.017.patch, HBASE-16488.revisit.v11-branch-1.patch, > HBASE-16488.v1-branch-1.patch, HBASE-16488.v1-master.patch, > HBASE-16488.v10-branch-1.patch, HBASE-16488.v2-branch-1.patch, > HBASE-16488.v2-branch-1.patch, HBASE-16488.v3-branch-1.patch, > HBASE-16488.v3-branch-1.patch, HBASE-16488.v4-branch-1.patch, > HBASE-16488.v5-branch-1.patch, HBASE-16488.v6-branch-1.patch, > HBASE-16488.v7-branch-1.patch, HBASE-16488.v8-branch-1.patch, > HBASE-16488.v9-branch-1.patch > > > From time to time, during internal IT test and from customer, we often see > master initialization failed due to namespace table region takes long time to > assign (eg. sometimes split log takes long time or hanging; or sometimes RS > is temporarily not available; sometimes due to some unknown assignment > issue). In the past, there was some proposal to improve this situation, eg. > HBASE-13556 / HBASE-14190 (Assign system tables ahead of user region > assignment) or HBASE-13557 (Special WAL handling for system tables) or > HBASE-14623 (Implement dedicated WAL for system tables). > This JIRA proposes another way to solve this master initialization fail > issue: namespace service is only used by a handful operations (eg. create > table / namespace DDL / get namespace API / some RS group DDL). Only quota > manager depends on it and quota management is off by default. Therefore, > namespace service is not really needed for master to be functional. So we > could start namespace service asynchronizely without blocking master startup. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22321) Add 1.5 release line to the Hadoop supported versions table
[ https://issues.apache.org/jira/browse/HBASE-22321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-22321: --- Attachment: HBASE-22321.patch > Add 1.5 release line to the Hadoop supported versions table > --- > > Key: HBASE-22321 > URL: https://issues.apache.org/jira/browse/HBASE-22321 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 1.5.0 > > Attachments: HBASE-22321.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-20026) Add 1.4 release line to the JDK and Hadoop expectation tables
[ https://issues.apache.org/jira/browse/HBASE-20026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-20026. Resolution: Not A Problem Fix Version/s: (was: 1.4.10) There is a column in [https://hbase.apache.org/book.html#hadoop] for "HBase 1.4.x" and I don't know of any special considerations for JDK. Resolving this as Not A Problem. Please reopen (and update description) if I've misunderstood. > Add 1.4 release line to the JDK and Hadoop expectation tables > - > > Key: HBASE-20026 > URL: https://issues.apache.org/jira/browse/HBASE-20026 > Project: HBase > Issue Type: Task > Components: documentation >Affects Versions: 1.4.0 >Reporter: Sean Busbey >Assignee: Andrew Purtell >Priority: Critical > > the ref guide currently doesn't have any expectations listed for branch-1.4 > releases around JDK and Hadoop versions. > either add it, or maybe update the existing entries so we have "1.2, 1.3, > 1.4" in a single entry. unless we're ready to include something different > among them. (Maybe note the default Hadoop we ship with? Or Hadoop 2.8.2+ > moving to S maybe? if we've actually done any of the legwork.) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HBASE-20026) Add 1.4 release line to the JDK and Hadoop expectation tables
[ https://issues.apache.org/jira/browse/HBASE-20026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell reassigned HBASE-20026: -- Assignee: Andrew Purtell > Add 1.4 release line to the JDK and Hadoop expectation tables > - > > Key: HBASE-20026 > URL: https://issues.apache.org/jira/browse/HBASE-20026 > Project: HBase > Issue Type: Task > Components: documentation >Affects Versions: 1.4.0 >Reporter: Sean Busbey >Assignee: Andrew Purtell >Priority: Critical > Fix For: 1.4.10 > > > the ref guide currently doesn't have any expectations listed for branch-1.4 > releases around JDK and Hadoop versions. > either add it, or maybe update the existing entries so we have "1.2, 1.3, > 1.4" in a single entry. unless we're ready to include something different > among them. (Maybe note the default Hadoop we ship with? Or Hadoop 2.8.2+ > moving to S maybe? if we've actually done any of the legwork.) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22274) Cell size limit check on append should consider cell's previous size.
[
https://issues.apache.org/jira/browse/HBASE-22274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827385#comment-16827385
]
Xu Cang commented on HBASE-22274:
-
The test #testCheckAndDeleteWithCompareOp is flaky. It fails at different
places at different time.
I put a debug log below. And I can see when it fails, the cell value is NULL.
Meaning the previous *'table.put'* did not put data or did not finish flush the
data before the check happens next line. And I checked in this test,
'autoFlush' is true.
So, I don't understand why Put can sometimes fail in this scenario.
{code:java}
table.put(put3);
ok = table.checkAndDelete(ROW, FAMILY, QUALIFIER, CompareOp.NOT_EQUAL, value4,
delete);
if(!ok){
Result resultGet = table.get(new Get(ROW));
LOG.info("debug " + resultGet.getValue(FAMILY,QUALIFIER));
}{code}
> Cell size limit check on append should consider cell's previous size.
> -
>
> Key: HBASE-22274
> URL: https://issues.apache.org/jira/browse/HBASE-22274
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 2.0.0, 1.3.5
>Reporter: Xu Cang
>Assignee: Xu Cang
>Priority: Minor
> Attachments: HBASE-22274-branch-1.001.patch,
> HBASE-22274-branch-1.002.patch, HBASE-22274-master.001.patch,
> HBASE-22274-master.002.patch, HBASE-22274-master.002.patch,
> HBASE-22274-master.003.patch
>
>
> Now we have cell size limit check based on this parameter
> *hbase.server.keyvalue.maxsize*
> One case was missing: appending to a cell only take append op's cell size
> into account against this limit check. we should check against the potential
> final cell size after the append.'
> It's easy to reproduce this :
>
> Apply this diff
>
> {code:java}
> diff --git
> a/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
>
> b/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
> index 5a285ef6ba..8633177ebe 100644 ---
> a/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
> +++
> b/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
> @@ -6455,7 +6455,7
> - t.append(new Append(ROW).addColumn(FAMILY, QUALIFIER, new byte[10 *
> 1024]));
> + t.append(new Append(ROW).addColumn(FAMILY, QUALIFIER, new byte[2 * 1024]));
> {code}
>
> Fix is to add this check in #reckonDeltas in HRegion class, where we have
> already got the appended cell's size.
> Will throw DoNotRetryIOException if checks is failed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22301) Consider rolling the WAL if the HDFS write pipeline is slow
[
https://issues.apache.org/jira/browse/HBASE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827383#comment-16827383
]
HBase QA commented on HBASE-22301:
--
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 13m
29s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {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 2 new or modified test
files. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
41s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
56s{color} | {color:green} branch-1 passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
4s{color} | {color:green} branch-1 passed with JDK v1.7.0_222 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
46s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
44s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
46s{color} | {color:green} branch-1 passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
0s{color} | {color:green} branch-1 passed with JDK v1.7.0_222 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
12s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
56s{color} | {color:green} the patch passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
5s{color} | {color:green} the patch passed with JDK v1.7.0_222 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s{color} | {color:green} The patch passed checkstyle in hbase-hadoop-compat
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
12s{color} | {color:green} The patch passed checkstyle in hbase-hadoop2-compat
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
22s{color} | {color:green} hbase-server: The patch generated 0 new + 94
unchanged - 6 fixed = 94 total (was 100) {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} 2m
50s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
1m 43s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
49s{color} | {color:green} the patch passed with JDK v1.8.0_212 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
2s{color} | {color:green} the patch passed with JDK v1.7.0_222 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
22s{color} | {color:green} hbase-hadoop-compat in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
29s{color} | {color:green}
[jira] [Updated] (HBASE-20993) [Auth] IPC client fallback to simple auth allowed doesn't work
[
https://issues.apache.org/jira/browse/HBASE-20993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-20993:
---
Fix Version/s: (was: 1.4.10)
1.4.11
> [Auth] IPC client fallback to simple auth allowed doesn't work
> --
>
> Key: HBASE-20993
> URL: https://issues.apache.org/jira/browse/HBASE-20993
> Project: HBase
> Issue Type: Bug
> Components: Client, IPC/RPC, security
>Affects Versions: 1.2.6, 1.3.2, 1.2.7, 1.4.7
>Reporter: Reid Chan
>Assignee: Reid Chan
>Priority: Critical
> Fix For: 1.5.0, 1.3.5, 1.4.11
>
> Attachments: HBASE-20993.001.patch,
> HBASE-20993.003.branch-1.flowchart.png, HBASE-20993.branch-1.002.patch,
> HBASE-20993.branch-1.003.patch, HBASE-20993.branch-1.004.patch,
> HBASE-20993.branch-1.005.patch, HBASE-20993.branch-1.006.patch,
> HBASE-20993.branch-1.007.patch, HBASE-20993.branch-1.008.patch,
> HBASE-20993.branch-1.009.patch, HBASE-20993.branch-1.009.patch,
> HBASE-20993.branch-1.010.patch, HBASE-20993.branch-1.011.patch,
> HBASE-20993.branch-1.012.patch, HBASE-20993.branch-1.2.001.patch,
> HBASE-20993.branch-1.wip.002.patch, HBASE-20993.branch-1.wip.patch,
> yetus-local-testpatch-output-009.txt
>
>
> It is easily reproducible.
> client's hbase-site.xml: hadoop.security.authentication:kerberos,
> hbase.security.authentication:kerberos,
> hbase.ipc.client.fallback-to-simple-auth-allowed:true, keytab and principal
> are right set
> A simple auth hbase cluster, a kerberized hbase client application.
> application trying to r/w/c/d table will have following exception:
> {code}
> javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Failed to find
> any Kerberos tgt)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:211)
> at
> org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:179)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:617)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$700(RpcClientImpl.java:162)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:743)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:740)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:740)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:906)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:873)
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1241)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:227)
> at
> org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:336)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$BlockingStub.isMasterRunning(MasterProtos.java:58383)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$MasterServiceStubMaker.isMasterRunning(ConnectionManager.java:1592)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$StubMaker.makeStubNoRetries(ConnectionManager.java:1530)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$StubMaker.makeStub(ConnectionManager.java:1552)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation$MasterServiceStubMaker.makeStub(ConnectionManager.java:1581)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.getKeepAliveMasterService(ConnectionManager.java:1738)
> at
> org.apache.hadoop.hbase.client.MasterCallable.prepare(MasterCallable.java:38)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:134)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.executeCallable(HBaseAdmin.java:4297)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.executeCallable(HBaseAdmin.java:4289)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.createTableAsyncV2(HBaseAdmin.java:753)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.createTable(HBaseAdmin.java:674)
> at
>
[jira] [Updated] (HBASE-21903) Backport major compaction tool HBASE-19528 from to 1.4 and 1.3
[ https://issues.apache.org/jira/browse/HBASE-21903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-21903: --- Fix Version/s: (was: 1.4.10) 1.4.11 > Backport major compaction tool HBASE-19528 from to 1.4 and 1.3 > -- > > Key: HBASE-21903 > URL: https://issues.apache.org/jira/browse/HBASE-21903 > Project: HBase > Issue Type: Task > Components: Client, Compaction, tooling >Affects Versions: 1.3.3, 1.4.9 >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan >Priority: Major > Fix For: 1.3.5, 1.4.11 > > Attachments: HBASE-21903-branch-1.3-addendum.patch > > > Our internal deployments are based on branch-1.3. We will be using the major > compaction tool HBASE-19528 from [~churromorales] and the enhancements on top > of it HBASE-21883 on our 1.3 clusters. I would like to backport HBASE-19528 > to 1.3 and hence 1.4 as well. Since its a standalone tool without any other > dependency or code changes, I believe that should be ok. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-22225) Profiler tab on Master/RS UI not working w/o comprehensive message
[
https://issues.apache.org/jira/browse/HBASE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827378#comment-16827378
]
Andrew Purtell edited comment on HBASE-5 at 4/26/19 11:58 PM:
--
Now we will present a simple error message that points to the relevant chapter
of the book:
!Screen Shot 2019-04-26 at 4.50.01 PM.jpg!
was (Author: apurtell):
Now we will present a simple error message that points to the relevant chapter
of the book:
!Screen Shot 2019-04-26 at 4.50.01 PM.jpg!
> Profiler tab on Master/RS UI not working w/o comprehensive message
> --
>
> Key: HBASE-5
> URL: https://issues.apache.org/jira/browse/HBASE-5
> Project: HBase
> Issue Type: Improvement
> Components: UI
>Affects Versions: 1.5.0
>Reporter: Yu Li
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 2.1.5, 2.2.1, 1.3.5
>
> Attachments: HBASE-5-branch-1.patch, HBASE-5.patch, Screen
> Shot 2019-04-26 at 4.50.01 PM.jpg
>
>
> As titled, when checking 1.5.0 RC3 binary package, clicking the "Profiler"
> tab on HMaster/RegionServer web UI, it complains page not found error like
> below:
> {noformat}
> Problem accessing /prof. Reason:
> NOT_FOUND
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22225) Profiler tab on Master/RS UI not working w/o comprehensive message
[
https://issues.apache.org/jira/browse/HBASE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-5:
---
Attachment: Screen Shot 2019-04-26 at 4.50.01 PM.jpg
> Profiler tab on Master/RS UI not working w/o comprehensive message
> --
>
> Key: HBASE-5
> URL: https://issues.apache.org/jira/browse/HBASE-5
> Project: HBase
> Issue Type: Improvement
> Components: UI
>Affects Versions: 1.5.0
>Reporter: Yu Li
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 2.1.5, 2.2.1, 1.3.5
>
> Attachments: HBASE-5-branch-1.patch, HBASE-5.patch, Screen
> Shot 2019-04-26 at 4.50.01 PM.jpg
>
>
> As titled, when checking 1.5.0 RC3 binary package, clicking the "Profiler"
> tab on HMaster/RegionServer web UI, it complains page not found error like
> below:
> {noformat}
> Problem accessing /prof. Reason:
> NOT_FOUND
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22225) Profiler tab on Master/RS UI not working w/o comprehensive message
[
https://issues.apache.org/jira/browse/HBASE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827378#comment-16827378
]
Andrew Purtell commented on HBASE-5:
Now we will present a simple error message that points to the relevant chapter
of the book:
!Screen Shot 2019-04-26 at 4.50.01 PM.jpg!
> Profiler tab on Master/RS UI not working w/o comprehensive message
> --
>
> Key: HBASE-5
> URL: https://issues.apache.org/jira/browse/HBASE-5
> Project: HBase
> Issue Type: Improvement
> Components: UI
>Affects Versions: 1.5.0
>Reporter: Yu Li
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 2.1.5, 2.2.1, 1.3.5
>
> Attachments: HBASE-5-branch-1.patch, HBASE-5.patch, Screen
> Shot 2019-04-26 at 4.50.01 PM.jpg
>
>
> As titled, when checking 1.5.0 RC3 binary package, clicking the "Profiler"
> tab on HMaster/RegionServer web UI, it complains page not found error like
> below:
> {noformat}
> Problem accessing /prof. Reason:
> NOT_FOUND
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22225) Profiler tab on Master/RS UI not working w/o comprehensive message
[
https://issues.apache.org/jira/browse/HBASE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-5:
---
Attachment: (was: Screen Shot 2019-04-26 at 4.50.01 PM.jpg)
> Profiler tab on Master/RS UI not working w/o comprehensive message
> --
>
> Key: HBASE-5
> URL: https://issues.apache.org/jira/browse/HBASE-5
> Project: HBase
> Issue Type: Improvement
> Components: UI
>Affects Versions: 1.5.0
>Reporter: Yu Li
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 2.1.5, 2.2.1, 1.3.5
>
> Attachments: HBASE-5-branch-1.patch, HBASE-5.patch
>
>
> As titled, when checking 1.5.0 RC3 binary package, clicking the "Profiler"
> tab on HMaster/RegionServer web UI, it complains page not found error like
> below:
> {noformat}
> Problem accessing /prof. Reason:
> NOT_FOUND
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22289) WAL-based log splitting resubmit threshold may result in a task being stuck forever
[
https://issues.apache.org/jira/browse/HBASE-22289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827377#comment-16827377
]
Sergey Shelukhin commented on HBASE-22289:
--
[~stack] the last patch should be good... :) checkstyle is a long line I can
fix on commit, and findbugs is the same issue already existing in this code
> WAL-based log splitting resubmit threshold may result in a task being stuck
> forever
> ---
>
> Key: HBASE-22289
> URL: https://issues.apache.org/jira/browse/HBASE-22289
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.0, 1.5.0
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22289.01-branch-2.1.patch,
> HBASE-22289.02-branch-2.1.patch, HBASE-22289.03-branch-2.1.patch
>
>
> Not sure if this is handled better in procedure based WAL splitting; in any
> case it affects versions before that.
> The problem is not in ZK as such but in internal state tracking in master, it
> seems.
> Master:
> {noformat}
> 2019-04-21 01:49:49,584 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Resubmitting task
> .1555831286638
> {noformat}
> worker-rs, split fails
> {noformat}
>
> 2019-04-21 02:05:31,774 INFO
> [RS_LOG_REPLAY_OPS-regionserver/:17020-1] wal.WALSplitter:
> Processed 24 edits across 2 regions; edits skipped=457; log
> file=.1555831286638, length=2156363702, corrupted=false, progress
> failed=true
> {noformat}
> Master (not sure about the delay of the acquired-message; at any rate it
> seems to detect the failure fine from this server)
> {noformat}
> 2019-04-21 02:11:14,928 INFO [main-EventThread]
> coordination.SplitLogManagerCoordination: Task .1555831286638 acquired
> by ,17020,139815097
> 2019-04-21 02:19:41,264 INFO
> [master/:17000.splitLogManager..Chore.1]
> coordination.SplitLogManagerCoordination: Skipping resubmissions of task
> .1555831286638 because threshold 3 reached
> {noformat}
> After that this task is stuck in the limbo forever with the old worker, and
> never resubmitted.
> RS never logs anything else for this task.
> Killing the RS on the worker unblocked the task and some other server did the
> split very quickly, so seems like master doesn't clear the worker name in its
> internal state when hitting the threshold... master never restarted so
> restarting the master might have also cleared it.
> This is extracted from splitlogmanager log messages, note the times.
> {noformat}
> 2019-04-21 02:2 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20,
>
> 2019-04-22 11:1 1555831286638=last_update = 1555837874928 last_version = 11
> cur_worker_name = ,17020,139815097 status = in_progress
> incarnation = 3 resubmits = 3 batch = installed = 24 done = 3 error = 20}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22225) Profiler tab on Master/RS UI not working w/o comprehensive message
[
https://issues.apache.org/jira/browse/HBASE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-5:
---
Attachment: HBASE-5.patch
HBASE-5-branch-1.patch
> Profiler tab on Master/RS UI not working w/o comprehensive message
> --
>
> Key: HBASE-5
> URL: https://issues.apache.org/jira/browse/HBASE-5
> Project: HBase
> Issue Type: Improvement
> Components: UI
>Affects Versions: 1.5.0
>Reporter: Yu Li
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 2.1.5, 2.2.1, 1.3.5
>
> Attachments: HBASE-5-branch-1.patch, HBASE-5.patch, Screen
> Shot 2019-04-26 at 4.50.01 PM.jpg
>
>
> As titled, when checking 1.5.0 RC3 binary package, clicking the "Profiler"
> tab on HMaster/RegionServer web UI, it complains page not found error like
> below:
> {noformat}
> Problem accessing /prof. Reason:
> NOT_FOUND
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22225) Profiler tab on Master/RS UI not working w/o comprehensive message
[
https://issues.apache.org/jira/browse/HBASE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-5:
---
Status: Patch Available (was: Open)
> Profiler tab on Master/RS UI not working w/o comprehensive message
> --
>
> Key: HBASE-5
> URL: https://issues.apache.org/jira/browse/HBASE-5
> Project: HBase
> Issue Type: Improvement
> Components: UI
>Affects Versions: 1.5.0
>Reporter: Yu Li
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 2.1.5, 2.2.1, 1.3.5
>
> Attachments: HBASE-5-branch-1.patch, HBASE-5.patch, Screen
> Shot 2019-04-26 at 4.50.01 PM.jpg
>
>
> As titled, when checking 1.5.0 RC3 binary package, clicking the "Profiler"
> tab on HMaster/RegionServer web UI, it complains page not found error like
> below:
> {noformat}
> Problem accessing /prof. Reason:
> NOT_FOUND
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22225) Profiler tab on Master/RS UI not working w/o comprehensive message
[
https://issues.apache.org/jira/browse/HBASE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-5:
---
Attachment: Screen Shot 2019-04-26 at 4.50.01 PM.jpg
> Profiler tab on Master/RS UI not working w/o comprehensive message
> --
>
> Key: HBASE-5
> URL: https://issues.apache.org/jira/browse/HBASE-5
> Project: HBase
> Issue Type: Improvement
> Components: UI
>Affects Versions: 1.5.0
>Reporter: Yu Li
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 2.1.5, 2.2.1, 1.3.5
>
> Attachments: HBASE-5-branch-1.patch, HBASE-5.patch, Screen
> Shot 2019-04-26 at 4.50.01 PM.jpg
>
>
> As titled, when checking 1.5.0 RC3 binary package, clicking the "Profiler"
> tab on HMaster/RegionServer web UI, it complains page not found error like
> below:
> {noformat}
> Problem accessing /prof. Reason:
> NOT_FOUND
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22086) space quota issue: deleting snapshot doesn't update the usage of table
[
https://issues.apache.org/jira/browse/HBASE-22086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827375#comment-16827375
]
HBase QA commented on HBASE-22086:
--
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
27s{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 2 new or modified test
files. {color} |
|| || || || {color:brown} branch-2 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
24s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
57s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
12s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
37s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
9s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
39s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
50s{color} | {color:green} branch-2 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
39s{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
2s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 5s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
51s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
31s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}134m
57s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
36s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}180m 7s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base:
https://builds.apache.org/job/PreCommit-HBASE-Build/200/artifact/patchprocess/Dockerfile
|
| JIRA Issue | HBASE-22086 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12967172/hbase-22086.branch-2.001.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 55d5de886534 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/hbase-personality.sh |
| git revision | branch-2 / aa9f36ae53 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java |
[jira] [Commented] (HBASE-22310) checkAndMutate used an incorrect row to check the condition
[ https://issues.apache.org/jira/browse/HBASE-22310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827355#comment-16827355 ] Hudson commented on HBASE-22310: SUCCESS: Integrated in Jenkins build HBase-1.3-IT #547 (See [https://builds.apache.org/job/HBase-1.3-IT/547/]) HBASE-22310 checkAndMutate used an incorrect row to check the condition (apurtell: [https://github.com/apache/hbase/commit/afc85c0e55d1bd9515214f7b2dd1a7838affb64f]) * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestCheckAndMutate.java > checkAndMutate used an incorrect row to check the condition > --- > > Key: HBASE-22310 > URL: https://issues.apache.org/jira/browse/HBASE-22310 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 1.3.3, 1.4.9 >Reporter: Adonis Ling >Assignee: Adonis Ling >Priority: Major > Fix For: 1.5.0, 1.4.10, 1.3.4 > > Attachments: HBASE-22310-branch-1.patch, > HBASE-22310.branch-1.3.001.patch, HBASE-22310.branch-1.3.002.patch, > HBASE-22310.branch-1.4.001.patch, HBASE-22310.branch-1.4.002.patch, > HBASE-22310.branch-1.4.003.patch > > > In branch-1.4, checkAndMutate used the row of RowMutation to check the > condition which is incorrect. It will fail in the case which is checking a > row and mutate a different row. > The issue doesn't happen in the master branch. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22301) Consider rolling the WAL if the HDFS write pipeline is slow
[ https://issues.apache.org/jira/browse/HBASE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827341#comment-16827341 ] Andrew Purtell commented on HBASE-22301: Updated patch for branch-1 with improvements as discussed > Consider rolling the WAL if the HDFS write pipeline is slow > --- > > Key: HBASE-22301 > URL: https://issues.apache.org/jira/browse/HBASE-22301 > Project: HBase > Issue Type: Improvement > Components: wal >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 3.0.0, 1.5.0, 2.3.0 > > Attachments: HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch, > HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch > > > Consider the case when a subset of the HDFS fleet is unhealthy but suffering > a gray failure not an outright outage. HDFS operations, notably syncs, are > abnormally slow on pipelines which include this subset of hosts. If the > regionserver's WAL is backed by an impacted pipeline, all WAL handlers can be > consumed waiting for acks from the datanodes in the pipeline (recall that > some of them are sick). Imagine a write heavy application distributing load > uniformly over the cluster at a fairly high rate. With the WAL subsystem > slowed by HDFS level issues, all handlers can be blocked waiting to append to > the WAL. Once all handlers are blocked, the application will experience > backpressure. All (HBase) clients eventually have too many outstanding writes > and block. > Because the application is distributing writes near uniformly in the > keyspace, the probability any given service endpoint will dispatch a request > to an impacted regionserver, even a single regionserver, approaches 1.0. So > the probability that all service endpoints will be affected approaches 1.0. > In order to break the logjam, we need to remove the slow datanodes. Although > there is HDFS level monitoring, mechanisms, and procedures for this, we > should also attempt to take mitigating action at the HBase layer as soon as > we find ourselves in trouble. It would be enough to remove the affected > datanodes from the writer pipelines. A super simple strategy that can be > effective is described below: > This is with branch-1 code. I think branch-2's async WAL can mitigate but > still can be susceptible. branch-2 sync WAL is susceptible. > We already roll the WAL writer if the pipeline suffers the failure of a > datanode and the replication factor on the pipeline is too low. We should > also consider how much time it took for the write pipeline to complete a sync > the last time we measured it, or the max over the interval from now to the > last time we checked. If the sync time exceeds a configured threshold, roll > the log writer then too. Fortunately we don't need to know which datanode is > making the WAL write pipeline slow, only that syncs on the pipeline are too > slow and exceeding a threshold. This is enough information to know when to > roll it. Once we roll it, we will get three new randomly selected datanodes. > On most clusters the probability the new pipeline includes the slow datanode > will be low. (And if for some reason it does end up with a problematic > datanode again, we roll again.) > This is not a silver bullet but this can be a reasonably effective mitigation. > Provide a metric for tracking when log roll is requested (and for what > reason). > Emit a log line at log roll time that includes datanode pipeline details for > further debugging and analysis, similar to the existing slow FSHLog sync log > line. > If we roll too many times within a short interval of time this probably means > there is a widespread problem with the fleet and so our mitigation is not > helping and may be exacerbating those problems or operator difficulties. > Ensure log roll requests triggered by this new feature happen infrequently > enough to not cause difficulties under either normal or abnormal conditions. > A very simple strategy that could work well under both normal and abnormal > conditions is to define a fairly lengthy interval, default 5 minutes, and > then insure we do not roll more than once during this interval for this > reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22301) Consider rolling the WAL if the HDFS write pipeline is slow
[ https://issues.apache.org/jira/browse/HBASE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-22301: --- Attachment: HBASE-22301-branch-1.patch > Consider rolling the WAL if the HDFS write pipeline is slow > --- > > Key: HBASE-22301 > URL: https://issues.apache.org/jira/browse/HBASE-22301 > Project: HBase > Issue Type: Improvement > Components: wal >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 3.0.0, 1.5.0, 2.3.0 > > Attachments: HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch, > HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch > > > Consider the case when a subset of the HDFS fleet is unhealthy but suffering > a gray failure not an outright outage. HDFS operations, notably syncs, are > abnormally slow on pipelines which include this subset of hosts. If the > regionserver's WAL is backed by an impacted pipeline, all WAL handlers can be > consumed waiting for acks from the datanodes in the pipeline (recall that > some of them are sick). Imagine a write heavy application distributing load > uniformly over the cluster at a fairly high rate. With the WAL subsystem > slowed by HDFS level issues, all handlers can be blocked waiting to append to > the WAL. Once all handlers are blocked, the application will experience > backpressure. All (HBase) clients eventually have too many outstanding writes > and block. > Because the application is distributing writes near uniformly in the > keyspace, the probability any given service endpoint will dispatch a request > to an impacted regionserver, even a single regionserver, approaches 1.0. So > the probability that all service endpoints will be affected approaches 1.0. > In order to break the logjam, we need to remove the slow datanodes. Although > there is HDFS level monitoring, mechanisms, and procedures for this, we > should also attempt to take mitigating action at the HBase layer as soon as > we find ourselves in trouble. It would be enough to remove the affected > datanodes from the writer pipelines. A super simple strategy that can be > effective is described below: > This is with branch-1 code. I think branch-2's async WAL can mitigate but > still can be susceptible. branch-2 sync WAL is susceptible. > We already roll the WAL writer if the pipeline suffers the failure of a > datanode and the replication factor on the pipeline is too low. We should > also consider how much time it took for the write pipeline to complete a sync > the last time we measured it, or the max over the interval from now to the > last time we checked. If the sync time exceeds a configured threshold, roll > the log writer then too. Fortunately we don't need to know which datanode is > making the WAL write pipeline slow, only that syncs on the pipeline are too > slow and exceeding a threshold. This is enough information to know when to > roll it. Once we roll it, we will get three new randomly selected datanodes. > On most clusters the probability the new pipeline includes the slow datanode > will be low. (And if for some reason it does end up with a problematic > datanode again, we roll again.) > This is not a silver bullet but this can be a reasonably effective mitigation. > Provide a metric for tracking when log roll is requested (and for what > reason). > Emit a log line at log roll time that includes datanode pipeline details for > further debugging and analysis, similar to the existing slow FSHLog sync log > line. > If we roll too many times within a short interval of time this probably means > there is a widespread problem with the fleet and so our mitigation is not > helping and may be exacerbating those problems or operator difficulties. > Ensure log roll requests triggered by this new feature happen infrequently > enough to not cause difficulties under either normal or abnormal conditions. > A very simple strategy that could work well under both normal and abnormal > conditions is to define a fairly lengthy interval, default 5 minutes, and > then insure we do not roll more than once during this interval for this > reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22254) refactor and improve decommissioning logic
[ https://issues.apache.org/jira/browse/HBASE-22254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-22254: --- Affects Version/s: 3.0.0 Status: Open (was: Patch Available) Just pointing out the obvious that the precommit results were failing on the new unit. Let me unset PA status until we have a new patch. > refactor and improve decommissioning logic > -- > > Key: HBASE-22254 > URL: https://issues.apache.org/jira/browse/HBASE-22254 > Project: HBase > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Major > Attachments: HBASE-22254.01.patch, HBASE-22254.patch > > > Making some changes needed to support better decommissioning on large > clusters and with container mode; to test those and add clarify I moved parts > of decommissioning logic from HMaster, Draining tracker, and ServerManager > into a separate class. > Features added/improvements: > 1) More resilient off-loading; right now off-loading fails for a subset of > regions in case of a single region failure; is never done on master restart, > etc. > 2) Option to kill RS after off-loading (good for container mode HBase, e.g. > on YARN). > 3) Option to specify machine names only to decommission, for the API to be > usable for an external system that doesn't care about HBase server names, or > e.g. multiple RS in containers on the same node. > 4) Option to replace existing decommissioning list instead of adding to it > (the same; to avoid additionally remembering what was previously sent to > HBase). > 5) Tests, comments ;) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[ https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827334#comment-16827334 ] Andrew Purtell commented on HBASE-22149: I don't object to a separate repo, of course > HBOSS: A FileSystem implementation to provide HBase's required semantics > > > Key: HBASE-22149 > URL: https://issues.apache.org/jira/browse/HBASE-22149 > Project: HBase > Issue Type: New Feature > Components: Filesystem Integration >Reporter: Sean Mackrory >Assignee: Sean Mackrory >Priority: Critical > Attachments: HBASE-22149-hadoop.patch, HBASE-22149-hbase-2.patch, > HBASE-22149-hbase-3.patch, HBASE-22149-hbase-4.patch, > HBASE-22149-hbase-5.patch, HBASE-22149-hbase.patch > > > (Have been using the name HBOSS for HBase / Object Store Semantics) > I've had some thoughts about how to solve the problem of running HBase on > object stores. There has been some thought in the past about adding the > required semantics to S3Guard, but I have some concerns about that. First, > it's mixing complicated solutions to different problems (bridging the gap > between a flat namespace and a hierarchical namespace vs. solving > inconsistency). Second, it's S3-specific, whereas other objects stores could > use virtually identical solutions. And third, we can't do things like atomic > renames in a true sense. There would have to be some trade-offs specific to > HBase's needs and it's better if we can solve that in an HBase-specific > module without mixing all that logic in with the rest of S3A. > Ideas to solve this above the FileSystem layer have been proposed and > considered (HBASE-20431, for one), and maybe that's the right way forward > long-term, but it certainly seems to be a hard problem and hasn't been done > yet. But I don't know enough of all the internal considerations to make much > of a judgment on that myself. > I propose a FileSystem implementation that wraps another FileSystem instance > and provides locking of FileSystem operations to ensure correct semantics. > Locking could quite possibly be done on the same ZooKeeper ensemble as an > HBase cluster already uses (I'm sure there are some performance > considerations here that deserve more attention). I've put together a > proof-of-concept on which I've tested some aspects of atomic renames and > atomic file creates. Both of these tests fail reliably on a naked s3a > instance. I've also done a small YCSB run against a small cluster to sanity > check other functionality and was successful. I will post the patch, and my > laundry list of things that still need work. The WAL is still placed on HDFS, > but the HBase root directory is otherwise on S3. > Note that my prototype is built on Hadoop's source tree right now. That's > purely for my convenience in putting it together quickly, as that's where I > mostly work. I actually think long-term, if this is accepted as a good > solution, it makes sense to live in HBase (or it's own repository). It only > depends on stable, public APIs in Hadoop and is targeted entirely at HBase's > needs, so it should be able to iterate on the HBase community's terms alone. > Another idea [~ste...@apache.org] proposed to me is that of an inode-based > FileSystem that keeps hierarchical metadata in a more appropriate store that > would allow the required transactions (maybe a special table in HBase could > provide that store itself for other tables), and stores the underlying files > with unique identifiers on S3. This allows renames to actually become fast > instead of just large atomic operations. It does however place a strong > dependency on the metadata store. I have not explored this idea much. My > current proof-of-concept has been pleasantly simple, so I think it's the > right solution unless it proves unable to provide the required performance > characteristics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[
https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827333#comment-16827333
]
Andrew Purtell commented on HBASE-22149:
{quote}The whole thing really depends on Hadoop 3+ (in production, S3Guard is
required and isn't in the Hadoop 2 releases,
{quote}
Hadoop advertises S3Guard in 2.9.2. Is this not production capable there?
Otherwise, I would really prefer testing this on 2.9.2 than any 3.x. That major
upgrade is off-putting (never mind that Hadoop's motto in previous years should
have been "every minor is a major" (smile))
> HBOSS: A FileSystem implementation to provide HBase's required semantics
>
>
> Key: HBASE-22149
> URL: https://issues.apache.org/jira/browse/HBASE-22149
> Project: HBase
> Issue Type: New Feature
> Components: Filesystem Integration
>Reporter: Sean Mackrory
>Assignee: Sean Mackrory
>Priority: Critical
> Attachments: HBASE-22149-hadoop.patch, HBASE-22149-hbase-2.patch,
> HBASE-22149-hbase-3.patch, HBASE-22149-hbase-4.patch,
> HBASE-22149-hbase-5.patch, HBASE-22149-hbase.patch
>
>
> (Have been using the name HBOSS for HBase / Object Store Semantics)
> I've had some thoughts about how to solve the problem of running HBase on
> object stores. There has been some thought in the past about adding the
> required semantics to S3Guard, but I have some concerns about that. First,
> it's mixing complicated solutions to different problems (bridging the gap
> between a flat namespace and a hierarchical namespace vs. solving
> inconsistency). Second, it's S3-specific, whereas other objects stores could
> use virtually identical solutions. And third, we can't do things like atomic
> renames in a true sense. There would have to be some trade-offs specific to
> HBase's needs and it's better if we can solve that in an HBase-specific
> module without mixing all that logic in with the rest of S3A.
> Ideas to solve this above the FileSystem layer have been proposed and
> considered (HBASE-20431, for one), and maybe that's the right way forward
> long-term, but it certainly seems to be a hard problem and hasn't been done
> yet. But I don't know enough of all the internal considerations to make much
> of a judgment on that myself.
> I propose a FileSystem implementation that wraps another FileSystem instance
> and provides locking of FileSystem operations to ensure correct semantics.
> Locking could quite possibly be done on the same ZooKeeper ensemble as an
> HBase cluster already uses (I'm sure there are some performance
> considerations here that deserve more attention). I've put together a
> proof-of-concept on which I've tested some aspects of atomic renames and
> atomic file creates. Both of these tests fail reliably on a naked s3a
> instance. I've also done a small YCSB run against a small cluster to sanity
> check other functionality and was successful. I will post the patch, and my
> laundry list of things that still need work. The WAL is still placed on HDFS,
> but the HBase root directory is otherwise on S3.
> Note that my prototype is built on Hadoop's source tree right now. That's
> purely for my convenience in putting it together quickly, as that's where I
> mostly work. I actually think long-term, if this is accepted as a good
> solution, it makes sense to live in HBase (or it's own repository). It only
> depends on stable, public APIs in Hadoop and is targeted entirely at HBase's
> needs, so it should be able to iterate on the HBase community's terms alone.
> Another idea [~ste...@apache.org] proposed to me is that of an inode-based
> FileSystem that keeps hierarchical metadata in a more appropriate store that
> would allow the required transactions (maybe a special table in HBase could
> provide that store itself for other tables), and stores the underlying files
> with unique identifiers on S3. This allows renames to actually become fast
> instead of just large atomic operations. It does however place a strong
> dependency on the metadata store. I have not explored this idea much. My
> current proof-of-concept has been pleasantly simple, so I think it's the
> right solution unless it proves unable to provide the required performance
> characteristics.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase-connectors] busbey merged pull request #26: HBASE-22318 Fix for warning The POM for org.glassfish.javax.el is missing
busbey merged pull request #26: HBASE-22318 Fix for warning The POM for org.glassfish.javax.el is missing URL: https://github.com/apache/hbase-connectors/pull/26 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-connectors] busbey commented on a change in pull request #26: HBASE-22318 Fix for warning The POM for org.glassfish.javax.el is missing
busbey commented on a change in pull request #26: HBASE-22318 Fix for warning The POM for org.glassfish.javax.el is missing URL: https://github.com/apache/hbase-connectors/pull/26#discussion_r279108282 ## File path: pom.xml ## @@ -139,6 +139,7 @@ comes in via hbase-thirdparty hbase-shaded-netty--> 3.6.2.Final 1.6.1 +3.0.1-b08 Review comment: I'm happy to match the hbase repo. :) 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-22310) checkAndMutate used an incorrect row to check the condition
[ https://issues.apache.org/jira/browse/HBASE-22310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-22310: --- Attachment: HBASE-22310-branch-1.patch > checkAndMutate used an incorrect row to check the condition > --- > > Key: HBASE-22310 > URL: https://issues.apache.org/jira/browse/HBASE-22310 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 1.3.3, 1.4.9 >Reporter: Adonis Ling >Assignee: Adonis Ling >Priority: Major > Fix For: 1.5.0, 1.4.10, 1.3.4 > > Attachments: HBASE-22310-branch-1.patch, > HBASE-22310.branch-1.3.001.patch, HBASE-22310.branch-1.3.002.patch, > HBASE-22310.branch-1.4.001.patch, HBASE-22310.branch-1.4.002.patch, > HBASE-22310.branch-1.4.003.patch > > > In branch-1.4, checkAndMutate used the row of RowMutation to check the > condition which is incorrect. It will fail in the case which is checking a > row and mutate a different row. > The issue doesn't happen in the master branch. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22310) checkAndMutate used an incorrect row to check the condition
[ https://issues.apache.org/jira/browse/HBASE-22310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-22310: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Attaching what I committed to branch-1.3, branch-1.4, and branch-1. > checkAndMutate used an incorrect row to check the condition > --- > > Key: HBASE-22310 > URL: https://issues.apache.org/jira/browse/HBASE-22310 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 1.3.3, 1.4.9 >Reporter: Adonis Ling >Assignee: Adonis Ling >Priority: Major > Fix For: 1.5.0, 1.4.10, 1.3.4 > > Attachments: HBASE-22310-branch-1.patch, > HBASE-22310.branch-1.3.001.patch, HBASE-22310.branch-1.3.002.patch, > HBASE-22310.branch-1.4.001.patch, HBASE-22310.branch-1.4.002.patch, > HBASE-22310.branch-1.4.003.patch > > > In branch-1.4, checkAndMutate used the row of RowMutation to check the > condition which is incorrect. It will fail in the case which is checking a > row and mutate a different row. > The issue doesn't happen in the master branch. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22291) Fix recovery of recovered.edits files under root dir
[ https://issues.apache.org/jira/browse/HBASE-22291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827324#comment-16827324 ] Zach York commented on HBASE-22291: --- Thanks [~apurtell]! > Fix recovery of recovered.edits files under root dir > > > Key: HBASE-22291 > URL: https://issues.apache.org/jira/browse/HBASE-22291 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.4.9 >Reporter: Zach York >Assignee: Zach York >Priority: Major > Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 2.1.5, 2.2.1, 1.3.5 > > Attachments: HBASE-22291.branch-1.001.patch, > HBASE-22291.master.001.patch, HBASE-22291.master.002.patch > > > It looks like a few places are using incorrect FS instances in the > replayRecoveredEditsForPath method that was introduced in HBASE-20734. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase-connectors] dbist commented on a change in pull request #26: HBASE-22318 Fix for warning The POM for org.glassfish.javax.el is missing
dbist commented on a change in pull request #26: HBASE-22318 Fix for warning The POM for org.glassfish.javax.el is missing URL: https://github.com/apache/hbase-connectors/pull/26#discussion_r279106315 ## File path: pom.xml ## @@ -139,6 +139,7 @@ comes in via hbase-thirdparty hbase-shaded-netty--> 3.6.2.Final 1.6.1 +3.0.1-b08 Review comment: I took it from hbase repo, I believe I first tested with b11, it failed for a reason I don't recall. I can try again. 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-14964) Backport HBASE-14901 to brach-1 - There is duplicated code to create/manage encryption keys
[ https://issues.apache.org/jira/browse/HBASE-14964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827321#comment-16827321 ] Nate Edel commented on HBASE-14964: --- I haven't been active on here in a long time; [~eclark] may have some context on whether this ever got followed up on. > Backport HBASE-14901 to brach-1 - There is duplicated code to create/manage > encryption keys > --- > > Key: HBASE-14964 > URL: https://issues.apache.org/jira/browse/HBASE-14964 > Project: HBase > Issue Type: Improvement > Components: encryption >Reporter: Nate Edel >Priority: Minor > Fix For: 1.5.0 > > Attachments: HBASE-14964-branch-1.1.patch, > HBASE-14964.1.branch-1.patch, HBASE-14964.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > There is duplicated code from MobUtils.createEncryptionContext in HStore, and > there is a subset of that code in HFileReaderImpl. > Refactored key selection > Moved both to EncryptionUtil.java > Can't figure out how to write a unit test for this, but there's no new code > just refactoring. > A lot of the Mob stuff hasn't been backported, so this is a very small patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HBASE-14964) Backport HBASE-14901 to brach-1 - There is duplicated code to create/manage encryption keys
[ https://issues.apache.org/jira/browse/HBASE-14964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate Edel reassigned HBASE-14964: - Assignee: (was: Nate Edel) > Backport HBASE-14901 to brach-1 - There is duplicated code to create/manage > encryption keys > --- > > Key: HBASE-14964 > URL: https://issues.apache.org/jira/browse/HBASE-14964 > Project: HBase > Issue Type: Improvement > Components: encryption >Reporter: Nate Edel >Priority: Minor > Fix For: 1.5.0 > > Attachments: HBASE-14964-branch-1.1.patch, > HBASE-14964.1.branch-1.patch, HBASE-14964.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > There is duplicated code from MobUtils.createEncryptionContext in HStore, and > there is a subset of that code in HFileReaderImpl. > Refactored key selection > Moved both to EncryptionUtil.java > Can't figure out how to write a unit test for this, but there's no new code > just refactoring. > A lot of the Mob stuff hasn't been backported, so this is a very small patch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22086) space quota issue: deleting snapshot doesn't update the usage of table
[ https://issues.apache.org/jira/browse/HBASE-22086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sakthi updated HBASE-22086: --- Attachment: hbase-22086.branch-2.001.patch > space quota issue: deleting snapshot doesn't update the usage of table > -- > > Key: HBASE-22086 > URL: https://issues.apache.org/jira/browse/HBASE-22086 > Project: HBase > Issue Type: Bug >Reporter: Ajeet Rai >Assignee: Sakthi >Priority: Minor > Labels: Quota, space > Fix For: 3.0.0 > > Attachments: hbase-22086.addendum.patch, > hbase-22086.branch-2.001.patch, hbase-22086.master.001.patch, > hbase-22086.master.002.patch, hbase-22086.master.003.patch, > hbase-22086.master.004.patch, hbase-22086.master.005.patch, > hbase-22086.master.006.patch > > > space quota issue: deleting snapshot doesn't update the usage of table > Steps: 1: > set_quota TYPE => SPACE, TABLE => 'bugatti', LIMIT => '7M', POLICY => > NO_WRITES_COMPACTIONS > 2: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10 > 3: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10 > 4: snapshot 'bugatti','bugatti_snapshot' > 5: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10 > 6: major_compact 'bugatti' > 7: delete_snapshot 'bugatti_snapshot' > now check the usage and observe that it is not getting updated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22086) space quota issue: deleting snapshot doesn't update the usage of table
[ https://issues.apache.org/jira/browse/HBASE-22086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827311#comment-16827311 ] Sakthi commented on HBASE-22086: Have attached the patches for both master & branch-2. Let's see what the qa has to say. > space quota issue: deleting snapshot doesn't update the usage of table > -- > > Key: HBASE-22086 > URL: https://issues.apache.org/jira/browse/HBASE-22086 > Project: HBase > Issue Type: Bug >Reporter: Ajeet Rai >Assignee: Sakthi >Priority: Minor > Labels: Quota, space > Fix For: 3.0.0 > > Attachments: hbase-22086.addendum.patch, > hbase-22086.branch-2.001.patch, hbase-22086.master.001.patch, > hbase-22086.master.002.patch, hbase-22086.master.003.patch, > hbase-22086.master.004.patch, hbase-22086.master.005.patch, > hbase-22086.master.006.patch > > > space quota issue: deleting snapshot doesn't update the usage of table > Steps: 1: > set_quota TYPE => SPACE, TABLE => 'bugatti', LIMIT => '7M', POLICY => > NO_WRITES_COMPACTIONS > 2: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10 > 3: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10 > 4: snapshot 'bugatti','bugatti_snapshot' > 5: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10 > 6: major_compact 'bugatti' > 7: delete_snapshot 'bugatti_snapshot' > now check the usage and observe that it is not getting updated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22086) space quota issue: deleting snapshot doesn't update the usage of table
[ https://issues.apache.org/jira/browse/HBASE-22086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sakthi updated HBASE-22086: --- Attachment: hbase-22086.master.006.patch > space quota issue: deleting snapshot doesn't update the usage of table > -- > > Key: HBASE-22086 > URL: https://issues.apache.org/jira/browse/HBASE-22086 > Project: HBase > Issue Type: Bug >Reporter: Ajeet Rai >Assignee: Sakthi >Priority: Minor > Labels: Quota, space > Fix For: 3.0.0 > > Attachments: hbase-22086.addendum.patch, > hbase-22086.master.001.patch, hbase-22086.master.002.patch, > hbase-22086.master.003.patch, hbase-22086.master.004.patch, > hbase-22086.master.005.patch, hbase-22086.master.006.patch > > > space quota issue: deleting snapshot doesn't update the usage of table > Steps: 1: > set_quota TYPE => SPACE, TABLE => 'bugatti', LIMIT => '7M', POLICY => > NO_WRITES_COMPACTIONS > 2: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10 > 3: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10 > 4: snapshot 'bugatti','bugatti_snapshot' > 5: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10 > 6: major_compact 'bugatti' > 7: delete_snapshot 'bugatti_snapshot' > now check the usage and observe that it is not getting updated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22239) Also catch RemoteException in SyncReplicationTestBase.verifyReplicationRequestRejection
[ https://issues.apache.org/jira/browse/HBASE-22239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-22239: -- Labels: async-client (was: ) > Also catch RemoteException in > SyncReplicationTestBase.verifyReplicationRequestRejection > --- > > Key: HBASE-22239 > URL: https://issues.apache.org/jira/browse/HBASE-22239 > Project: HBase > Issue Type: Sub-task > Components: asyncclient >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Labels: async-client > Fix For: HBASE-21512 > > Attachments: HBASE-22239-HBASE-21512.patch > > > See the last few comments in HBASE-22303. We do not have short circuit > connection for async client so we need to deal with RemoteException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22313) Add a method to FsDelegationToken to accept token kind
[ https://issues.apache.org/jira/browse/HBASE-22313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-22313: -- Component/s: security > Add a method to FsDelegationToken to accept token kind > -- > > Key: HBASE-22313 > URL: https://issues.apache.org/jira/browse/HBASE-22313 > Project: HBase > Issue Type: New Feature > Components: security >Reporter: Venkatesh Sridharan >Priority: Minor > > The acquireDelegationToken method [1] defaults to checking for delegation > token of kind "HDFS_DELEGATION_TOKEN" before fetching it from the FileSystem. > It would be helpful to have a method that accepts the token kind and fetches > delegation token from UserProvider for that token kind. > [1] - > [https://github.com/apache/hbase/blob/rel/2.1.4/hbase-server/src/main/java/org/apache/hadoop/hbase/security/token/FsDelegationToken.java#L67] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22316) Consider always creating a new exception in FutureUtils.get
[ https://issues.apache.org/jira/browse/HBASE-22316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-22316: -- Labels: async-client (was: ) > Consider always creating a new exception in FutureUtils.get > --- > > Key: HBASE-22316 > URL: https://issues.apache.org/jira/browse/HBASE-22316 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Priority: Major > Labels: async-client > > This is for debugging. As in async client, the retry will be done in the > retry timer thread, so the exception we get from the CompletableFuture will > have a stack trace starting from the root of the retry timer. If we just > throw this exception out when calling future.get(by unwrapping the > ExecutionException), the upper layer even can not know where is the exception > thrown... > This happens for me many times, so I propose that we always create a new > exception in FutureUtils.get, so at least we can record the stack trace for > the method calling FutureUtils.get... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase-connectors] busbey commented on a change in pull request #26: HBASE-22318 Fix for warning The POM for org.glassfish.javax.el is missing
busbey commented on a change in pull request #26: HBASE-22318 Fix for warning The POM for org.glassfish.javax.el is missing URL: https://github.com/apache/hbase-connectors/pull/26#discussion_r279094581 ## File path: pom.xml ## @@ -139,6 +139,7 @@ comes in via hbase-thirdparty hbase-shaded-netty--> 3.6.2.Final 1.6.1 +3.0.1-b08 Review comment: how'd you come up with `3.0.1-b08` here? looking at the mvn install run from before the patch it looks like we end up getting `3.0.1-b11`. 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-22320) hbase-connectors personality skips non-scaladoc tests
[ https://issues.apache.org/jira/browse/HBASE-22320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Biju Nair updated HBASE-22320: -- Labels: connector (was: ) > hbase-connectors personality skips non-scaladoc tests > - > > Key: HBASE-22320 > URL: https://issues.apache.org/jira/browse/HBASE-22320 > Project: HBase > Issue Type: Bug >Affects Versions: connector-1.0.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Labels: connector > Fix For: connector-1.0.1 > > > see discussion on PR 26 > https://github.com/apache/hbase-connectors/pull/26 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase-connectors] asfgit commented on issue #26: HBASE-22318 Fix for warning The POM for org.glassfish.javax.el is missing
asfgit commented on issue #26: HBASE-22318 Fix for warning The POM for org.glassfish.javax.el is missing URL: https://github.com/apache/hbase-connectors/pull/26#issuecomment-487189121 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/PreCommit-HBASE-CONNECTORS-Build/41/ 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-22314) shaded byo-hadoop client should list needed hadoop modules as provided scope to avoid inclusion of unnecessary transitive depednencies
[ https://issues.apache.org/jira/browse/HBASE-22314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827275#comment-16827275 ] Sean Busbey commented on HBASE-22314: - signed off by Stack and William Shen in PR 192 https://github.com/apache/hbase/pull/192 > shaded byo-hadoop client should list needed hadoop modules as provided scope > to avoid inclusion of unnecessary transitive depednencies > -- > > Key: HBASE-22314 > URL: https://issues.apache.org/jira/browse/HBASE-22314 > Project: HBase > Issue Type: Bug > Components: hadoop2, hadoop3, shading >Affects Versions: 2.1.0, 2.0.0, 2.2.0, 2.3.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Major > Fix For: 3.0.0, 2.3.0, 2.0.6, 2.1.5, 2.2.1 > > Attachments: HBASE-22314.0.patch > > > attempting to build against current hadoop trunk for HBASE-22087 shows that > hte byo-hadoop client is trying to package transitive dependencies from the > hadoop dependencies that we expressly say we don't need to bring with us. > it's because we don't list those modules as provided, so all of their > transitives are also in compile scope. The shading module does simple > filtering when excluding things in a given scope, it doesn't e.g. make sure > to also exclude the transitive dependencies of things it keeps out. > since we don't want to list all the transitive dependencies of hadoop in our > shading exclusion, we should list the needed hadoop modules as provided. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22087) Update LICENSE/shading for the dependencies from the latest Hadoop trunk
[ https://issues.apache.org/jira/browse/HBASE-22087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827279#comment-16827279 ] Sean Busbey commented on HBASE-22087: - signed off by Stack and William Shen in PR 192 https://github.com/apache/hbase/pull/192 > Update LICENSE/shading for the dependencies from the latest Hadoop trunk > > > Key: HBASE-22087 > URL: https://issues.apache.org/jira/browse/HBASE-22087 > Project: HBase > Issue Type: Improvement > Components: hadoop3 >Reporter: Wei-Chiu Chuang >Assignee: Wei-Chiu Chuang >Priority: Minor > Attachments: HBASE-22087.master.001.patch, depcheck_hadoop33.log > > > The following list of dependencies were added in Hadoop trunk (3.3.0) and > HBase does not compile successfully: > YARN-8778 added jline 3.9.0 > HADOOP-15775 added javax.activation > HADOOP-15531 added org.apache.common.text (commons-text) > HADOOP-15764 added dnsjava (org.xbill) > Some of these are needed to support JDK9/10/11 in Hadoop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22109) Update hbase shaded content checker after guava update in hadoop branch-3.0 to 27.0-jre
[ https://issues.apache.org/jira/browse/HBASE-22109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827277#comment-16827277 ] Sean Busbey commented on HBASE-22109: - signed off by Stack and William Shen in PR 192 https://github.com/apache/hbase/pull/192 > Update hbase shaded content checker after guava update in hadoop branch-3.0 > to 27.0-jre > --- > > Key: HBASE-22109 > URL: https://issues.apache.org/jira/browse/HBASE-22109 > Project: HBase > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Gabor Bota >Assignee: Gabor Bota >Priority: Minor > Attachments: HBASE-22109.001.patch > > > I'm updating guava version from 11.0.2 to 27.0-jre in HADOOP-15960 because of > a CVE. I will create a patch for branch-3.0, 3.1, 3.2 and trunk (3.3). > I wanted to be sure that HBase works with the updated guava, I compiled and > run the HBase tests with my hadoop snapshot containing the updated version, > but there were some issues that I had to fix: > * New shaded dependency: org.checkerframework > * New license needs to be added to LICENSE.vm: Apache 2.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22312) Hadoop 3 profile for hbase-shaded-mapreduce should like mapreduce as a provided dependency
[ https://issues.apache.org/jira/browse/HBASE-22312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827274#comment-16827274 ] Sean Busbey commented on HBASE-22312: - signed off by Stack and William Shen in PR 192 https://github.com/apache/hbase/pull/192 > Hadoop 3 profile for hbase-shaded-mapreduce should like mapreduce as a > provided dependency > -- > > Key: HBASE-22312 > URL: https://issues.apache.org/jira/browse/HBASE-22312 > Project: HBase > Issue Type: Bug > Components: mapreduce, shading >Affects Versions: 2.1.0, 2.0.0, 2.0.1, 2.2.0, 2.1.1, 2.0.2, 2.0.3, 2.1.2, > 2.0.4, 2.1.3, 2.0.5, 2.1.4 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Major > Fix For: 3.0.0, 2.3.0, 2.0.6, 2.1.5, 2.2.1 > > Attachments: HBASE-22312.0.patch > > > the hadoop 3 profile currently misses declaring a provided dependency on the > core mapreduce client module. that means we pick it up as a compile > dependency from the hbase-mapreduce module, which means we include things in > the shaded jar that we don't need to. (and expressly aren't supposed to > include because they're supposed to come from Hadoop at runtime). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase] busbey commented on issue #192: Related jiras that update our handling of Hadoop transitive dependencies
busbey commented on issue #192: Related jiras that update our handling of Hadoop transitive dependencies URL: https://github.com/apache/hbase/pull/192#issuecomment-487187694 arg. merge button doesn't include review sign off in the git commit information. 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-connectors] meszibalu commented on issue #29: HBASE-22320 hbase-connectors personality skips non-scaladoc tests
meszibalu commented on issue #29: HBASE-22320 hbase-connectors personality skips non-scaladoc tests URL: https://github.com/apache/hbase-connectors/pull/29#issuecomment-487187262 Thanks @busbey ! 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-connectors] petersomogyi commented on issue #26: HBASE-22318 Fix for warning The POM for org.glassfish.javax.el is missing
petersomogyi commented on issue #26: HBASE-22318 Fix for warning The POM for org.glassfish.javax.el is missing URL: https://github.com/apache/hbase-connectors/pull/26#issuecomment-487185477 retest build 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] [Resolved] (HBASE-22320) hbase-connectors personality skips non-scaladoc tests
[ https://issues.apache.org/jira/browse/HBASE-22320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey resolved HBASE-22320. - Resolution: Fixed > hbase-connectors personality skips non-scaladoc tests > - > > Key: HBASE-22320 > URL: https://issues.apache.org/jira/browse/HBASE-22320 > Project: HBase > Issue Type: Bug >Affects Versions: connector-1.0.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: connector-1.0.1 > > > see discussion on PR 26 > https://github.com/apache/hbase-connectors/pull/26 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase-connectors] busbey commented on issue #26: HBASE-22318 Fix for warning The POM for org.glassfish.javax.el is missing
busbey commented on issue #26: HBASE-22318 Fix for warning The POM for org.glassfish.javax.el is missing URL: https://github.com/apache/hbase-connectors/pull/26#issuecomment-487184139 @dbist can you rebase onto the latest master branch? the CI bot should properly run tests now. 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-connectors] busbey merged pull request #29: HBASE-22320 hbase-connectors personality skips non-scaladoc tests
busbey merged pull request #29: HBASE-22320 hbase-connectors personality skips non-scaladoc tests URL: https://github.com/apache/hbase-connectors/pull/29 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] busbey commented on a change in pull request #192: Related jiras that update our handling of Hadoop transitive dependencies
busbey commented on a change in pull request #192: Related jiras that update our handling of Hadoop transitive dependencies URL: https://github.com/apache/hbase/pull/192#discussion_r279085956 ## File path: hbase-resource-bundle/src/main/resources/supplemental-models.xml ## @@ -977,6 +977,24 @@ Copyright 2010 FasterXML.com + + + org.jline + jline + 3.9.0 + + + BSD license + https://opensource.org/licenses/BSD-3-Clause + repo + +Copyright (c) 2002-2018, the original author or authors. Review comment: not unless the version of jline we end up packaging is from 2019. 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] busbey merged pull request #192: Related jiras that update our handling of Hadoop transitive dependencies
busbey merged pull request #192: Related jiras that update our handling of Hadoop transitive dependencies URL: https://github.com/apache/hbase/pull/192 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-19663) site build fails complaining "javadoc: error - class file for javax.annotation.meta.TypeQualifierNickname not found"
[
https://issues.apache.org/jira/browse/HBASE-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827252#comment-16827252
]
Sean Busbey commented on HBASE-19663:
-
I figured out what the problem is, but I'm not sure of the solution.
the reference to the JSR305 annotation TypeQualifierNickname happens in the
findbugs-annotations classes we reference (Nullable, NotNull, etc)
The difference here is one of error handling between the doclet from Yetus and
the standard doclet. For the standard doclet, it looks like any missed
annotation definition results in a warning. for the doclet from Yetus, if the
classes we're documenting have an annotation that's missing it causes a
warning. but if there is a class definition for an annotation we use, then that
class must be fully referenceable.
So. If I modify the javadoc wrapper script that is created by the
maven-javadoc-plugin to either remove the findbugs-annotations jar or add in
the jsr305 jar, things work. Since we don't tell javadoc to link in the
annotations from the findbugs-annotations package the resulting javadocs are
even equivalent.
I'm not sure what the best answer is here. I suspect removing the
findbugs-annotations jar from the classpath needed for javadoc generation will
be difficult. Adding in jsr305 for just javadocs is pretty easy.
There's also not that many references, so maybe we could just get rid of this
annotation use. I'm not sure what the story is for them in newer versions of
spotbugs.
{code}
git grep "edu.umd.cs.findbugs.annotations" | wc -l
134
{code}
> site build fails complaining "javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found"
>
>
> Key: HBASE-19663
> URL: https://issues.apache.org/jira/browse/HBASE-19663
> Project: HBase
> Issue Type: Bug
> Components: website
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: script.sh
>
>
> Cryptic failure trying to build beta-1 RC. Fails like this:
> {code}
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 03:54 min
> [INFO] Finished at: 2017-12-29T01:13:15-08:00
> [INFO] Final Memory: 381M/9165M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
> hbase: Error generating maven-javadoc-plugin:2.10.3:aggregate:
> [ERROR] Exit code: 1 - warning: unknown enum constant When.ALWAYS
> [ERROR] reason: class file for javax.annotation.meta.When not found
> [ERROR] warning: unknown enum constant When.UNKNOWN
> [ERROR] warning: unknown enum constant When.MAYBE
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: malformed: "#matchingRows(Cell, byte[]))"
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR] javadoc: warning - Class javax.annotation.Nonnull not found.
> [ERROR] javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found
> [ERROR]
> [ERROR] Command line was: /home/stack/bin/jdk1.8.0_151/jre/../bin/javadoc
> -J-Xmx2G @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/stack/hbase.git/target/site/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}
> javax.annotation.meta.TypeQualifierNickname is out of jsr305 but we don't
> include this anywhere according to mvn dependency.
> Happens building the User API both test and main.
> Excluding these lines gets us passing again:
> {code}
> 3511
> 3512
> org.apache.yetus.audience.tools.IncludePublicAnnotationsStandardDoclet
> 3513
> 3514
> 3515 org.apache.yetus
> 3516 audience-annotations
> 3517 ${audience-annotations.version}
> 3518
> + 3519 true
>
[jira] [Commented] (HBASE-22086) space quota issue: deleting snapshot doesn't update the usage of table
[ https://issues.apache.org/jira/browse/HBASE-22086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827251#comment-16827251 ] Sakthi commented on HBASE-22086: Yes working on it [~elserj]. > space quota issue: deleting snapshot doesn't update the usage of table > -- > > Key: HBASE-22086 > URL: https://issues.apache.org/jira/browse/HBASE-22086 > Project: HBase > Issue Type: Bug >Reporter: Ajeet Rai >Assignee: Sakthi >Priority: Minor > Labels: Quota, space > Fix For: 3.0.0 > > Attachments: hbase-22086.addendum.patch, > hbase-22086.master.001.patch, hbase-22086.master.002.patch, > hbase-22086.master.003.patch, hbase-22086.master.004.patch, > hbase-22086.master.005.patch > > > space quota issue: deleting snapshot doesn't update the usage of table > Steps: 1: > set_quota TYPE => SPACE, TABLE => 'bugatti', LIMIT => '7M', POLICY => > NO_WRITES_COMPACTIONS > 2: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10 > 3: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10 > 4: snapshot 'bugatti','bugatti_snapshot' > 5: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10 > 6: major_compact 'bugatti' > 7: delete_snapshot 'bugatti_snapshot' > now check the usage and observe that it is not getting updated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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=16827248#comment-16827248
]
Hudson commented on HBASE-21879:
Results for branch HBASE-21879
[build #79 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/79/]:
(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/79//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/79//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/79//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.3#76005)
[jira] [Commented] (HBASE-21512) Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
[
https://issues.apache.org/jira/browse/HBASE-21512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827225#comment-16827225
]
Hudson commented on HBASE-21512:
Results for branch HBASE-21512
[build #198 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/198/]:
(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-21512/198//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/HBASE-21512/198//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-21512/198//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
> --
>
> Key: HBASE-21512
> URL: https://issues.apache.org/jira/browse/HBASE-21512
> Project: HBase
> Issue Type: Umbrella
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
>
> At least for the RSProcedureDispatcher, with CompletableFuture we do not need
> to set a delay and use a thread pool any more, which could reduce the
> resource usage and also the latency.
> Once this is done, I think we can remove the ClusterConnection completely,
> and start to rewrite the old sync client based on the async client, which
> could reduce the code base a lot for our client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] willshen commented on a change in pull request #192: Related jiras that update our handling of Hadoop transitive dependencies
willshen commented on a change in pull request #192: Related jiras that update our handling of Hadoop transitive dependencies URL: https://github.com/apache/hbase/pull/192#discussion_r279054742 ## File path: hbase-resource-bundle/src/main/resources/supplemental-models.xml ## @@ -977,6 +977,24 @@ Copyright 2010 FasterXML.com + + + org.jline + jline + 3.9.0 + + + BSD license + https://opensource.org/licenses/BSD-3-Clause + repo + +Copyright (c) 2002-2018, the original author or authors. Review comment: just wondering, does it matter that we are in 2019 now? 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] [Comment Edited] (HBASE-22298) branch-2.2 nightly fails "[ForOverride] Method annotated @ForOverride must have protected or package-private visibility"
[
https://issues.apache.org/jira/browse/HBASE-22298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827188#comment-16827188
]
stack edited comment on HBASE-22298 at 4/26/19 6:20 PM:
Can you update your password [~zghaobac] ?
https://reference.apache.org/committer/id
was (Author: stack):
Can you update your password [~zghaobac] ?
> branch-2.2 nightly fails "[ForOverride] Method annotated @ForOverride must
> have protected or package-private visibility"
>
>
> Key: HBASE-22298
> URL: https://issues.apache.org/jira/browse/HBASE-22298
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 3.0.0, 2.3.0, 2.1.5, 2.2.1
>
> Attachments: HBASE-22298.branch-2.2.001.patch
>
>
> The change to use guava service happened a long time ago but we errorprone
> only complains now... update?
> {code}
>
> [INFO] 97 warnings
> [INFO] -
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /testptch/hbase/hbase-server/src/main/java/org/apache/hadoop/hbase/master/ClusterSchemaServiceImpl.java:[60,27]
> error: [ForOverride] Method annotated @ForOverride must have protected or
> package-private visibility
> (see https://errorprone.info/bugpattern/ForOverride)
> [INFO] 1 error
> {code}
> See https://errorprone.info/bugpattern/ForOverride
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22298) branch-2.2 nightly fails "[ForOverride] Method annotated @ForOverride must have protected or package-private visibility"
[
https://issues.apache.org/jira/browse/HBASE-22298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827188#comment-16827188
]
stack commented on HBASE-22298:
---
Can you update your password [~zghaobac] ?
> branch-2.2 nightly fails "[ForOverride] Method annotated @ForOverride must
> have protected or package-private visibility"
>
>
> Key: HBASE-22298
> URL: https://issues.apache.org/jira/browse/HBASE-22298
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 3.0.0, 2.3.0, 2.1.5, 2.2.1
>
> Attachments: HBASE-22298.branch-2.2.001.patch
>
>
> The change to use guava service happened a long time ago but we errorprone
> only complains now... update?
> {code}
>
> [INFO] 97 warnings
> [INFO] -
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /testptch/hbase/hbase-server/src/main/java/org/apache/hadoop/hbase/master/ClusterSchemaServiceImpl.java:[60,27]
> error: [ForOverride] Method annotated @ForOverride must have protected or
> package-private visibility
> (see https://errorprone.info/bugpattern/ForOverride)
> [INFO] 1 error
> {code}
> See https://errorprone.info/bugpattern/ForOverride
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-17884) Backport HBASE-16217 to branch-1
[ https://issues.apache.org/jira/browse/HBASE-17884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-17884: --- Fix Version/s: (was: 1.4.10) > Backport HBASE-16217 to branch-1 > > > Key: HBASE-17884 > URL: https://issues.apache.org/jira/browse/HBASE-17884 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors, security >Reporter: Gary Helmling >Assignee: Gary Helmling >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-17884-branch-1.patch, HBASE-17884-branch-1.patch, > HBASE-17884.branch-1.001.patch > > > The change to add calling user to ObserverContext in HBASE-16217 should also > be applied to branch-1 to avoid use of UserGroupInformation.doAs() for access > control checks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-17884) Backport HBASE-16217 to branch-1
[ https://issues.apache.org/jira/browse/HBASE-17884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827183#comment-16827183 ] Andrew Purtell commented on HBASE-17884: Hmm. I pushed a revert to branch-1.4 and updated the fixversions. I think this resolves the problem on our side. In general, we are allowed to break CP APIs at minor releases unless they are specially marked as Stable. That said, nobody wants to break Phoenix on a whim. However in this case I think nobody should be extending ObserverContext, this seems like an internal implementation detail. They can be referenced, of course, we are going to be careful to preserve interface compatibility for getters, setters, and other methods, but constructors, not so much, as we expect HBase is the only one constructing these, for the CP upcalls. This could be an ongoing source of fragility. > Backport HBASE-16217 to branch-1 > > > Key: HBASE-17884 > URL: https://issues.apache.org/jira/browse/HBASE-17884 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors, security >Reporter: Gary Helmling >Assignee: Gary Helmling >Priority: Major > Fix For: 1.5.0, 1.4.10 > > Attachments: HBASE-17884-branch-1.patch, HBASE-17884-branch-1.patch, > HBASE-17884.branch-1.001.patch > > > The change to add calling user to ObserverContext in HBASE-16217 should also > be applied to branch-1 to avoid use of UserGroupInformation.doAs() for access > control checks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22086) space quota issue: deleting snapshot doesn't update the usage of table
[
https://issues.apache.org/jira/browse/HBASE-22086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827180#comment-16827180
]
Josh Elser commented on HBASE-22086:
{quote}This breaks TestQuotaTableUtil.testDeleteSnapshots.
{quote}
Sorry about that Duo. How did we miss this? QA looks like it ran hbase-server
tests:
[https://builds.apache.org/job/PreCommit-HBASE-Build/67/testReport/org.apache.hadoop.hbase.quotas/TestQuotaTableUtil/].
Some other change came in after QA but before I committed, maybe?
{quote}Will amend the addendum to the original patch as well in that case and
will upload.{quote}
SGTM. You doing the branch-2 patch(es) at the same time too, please?
> space quota issue: deleting snapshot doesn't update the usage of table
> --
>
> Key: HBASE-22086
> URL: https://issues.apache.org/jira/browse/HBASE-22086
> Project: HBase
> Issue Type: Bug
>Reporter: Ajeet Rai
>Assignee: Sakthi
>Priority: Minor
> Labels: Quota, space
> Fix For: 3.0.0
>
> Attachments: hbase-22086.addendum.patch,
> hbase-22086.master.001.patch, hbase-22086.master.002.patch,
> hbase-22086.master.003.patch, hbase-22086.master.004.patch,
> hbase-22086.master.005.patch
>
>
> space quota issue: deleting snapshot doesn't update the usage of table
> Steps: 1:
> set_quota TYPE => SPACE, TABLE => 'bugatti', LIMIT => '7M', POLICY =>
> NO_WRITES_COMPACTIONS
> 2: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10
> 3: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10
> 4: snapshot 'bugatti','bugatti_snapshot'
> 5: ./hbase pe --table="bugatti" --nomapred --rows=200 sequentialWrite 10
> 6: major_compact 'bugatti'
> 7: delete_snapshot 'bugatti_snapshot'
> now check the usage and observe that it is not getting updated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22310) checkAndMutate used an incorrect row to check the condition
[ https://issues.apache.org/jira/browse/HBASE-22310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827176#comment-16827176 ] Andrew Purtell commented on HBASE-22310: So, the hadoopcheck issues should go away after a test personality update (if we opt for that). For now I'll ignore them. I think the unit test failures are also unrelated but let me check locally. Otherwise will commit this. > checkAndMutate used an incorrect row to check the condition > --- > > Key: HBASE-22310 > URL: https://issues.apache.org/jira/browse/HBASE-22310 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 1.3.3, 1.4.9 >Reporter: Adonis Ling >Assignee: Adonis Ling >Priority: Major > Fix For: 1.5.0, 1.4.10, 1.3.4 > > Attachments: HBASE-22310.branch-1.3.001.patch, > HBASE-22310.branch-1.3.002.patch, HBASE-22310.branch-1.4.001.patch, > HBASE-22310.branch-1.4.002.patch, HBASE-22310.branch-1.4.003.patch > > > In branch-1.4, checkAndMutate used the row of RowMutation to check the > condition which is incorrect. It will fail in the case which is checking a > row and mutate a different row. > The issue doesn't happen in the master branch. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22310) checkAndMutate used an incorrect row to check the condition
[ https://issues.apache.org/jira/browse/HBASE-22310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-22310: --- Fix Version/s: 1.3.4 1.4.10 1.5.0 > checkAndMutate used an incorrect row to check the condition > --- > > Key: HBASE-22310 > URL: https://issues.apache.org/jira/browse/HBASE-22310 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 1.3.3, 1.4.9 >Reporter: Adonis Ling >Assignee: Adonis Ling >Priority: Major > Fix For: 1.5.0, 1.4.10, 1.3.4 > > Attachments: HBASE-22310.branch-1.3.001.patch, > HBASE-22310.branch-1.3.002.patch, HBASE-22310.branch-1.4.001.patch, > HBASE-22310.branch-1.4.002.patch, HBASE-22310.branch-1.4.003.patch > > > In branch-1.4, checkAndMutate used the row of RowMutation to check the > condition which is incorrect. It will fail in the case which is checking a > row and mutate a different row. > The issue doesn't happen in the master branch. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22310) checkAndMutate used an incorrect row to check the condition
[
https://issues.apache.org/jira/browse/HBASE-22310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827172#comment-16827172
]
Andrew Purtell commented on HBASE-22310:
{quote}do we support Hadoop 2.4-2.6 on 1.4 release line? The personality file
defines it but Reference guide claims to be only Hadoop-2.7.1+.
{quote}
That is really a question of community consensus.
If we believe the reference guide is the most up to date representation of
consensus on support, then only Hadoop 2.7 and up are supported.
If we look at git history, the 1.4.0 release had 2.7.4 defined as
{{hadoop-two.version}} . I think this could also be construed as intent.
> checkAndMutate used an incorrect row to check the condition
> ---
>
> Key: HBASE-22310
> URL: https://issues.apache.org/jira/browse/HBASE-22310
> Project: HBase
> Issue Type: Bug
> Components: API
>Affects Versions: 1.3.3, 1.4.9
>Reporter: Adonis Ling
>Assignee: Adonis Ling
>Priority: Major
> Attachments: HBASE-22310.branch-1.3.001.patch,
> HBASE-22310.branch-1.3.002.patch, HBASE-22310.branch-1.4.001.patch,
> HBASE-22310.branch-1.4.002.patch, HBASE-22310.branch-1.4.003.patch
>
>
> In branch-1.4, checkAndMutate used the row of RowMutation to check the
> condition which is incorrect. It will fail in the case which is checking a
> row and mutate a different row.
> The issue doesn't happen in the master branch.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22310) checkAndMutate used an incorrect row to check the condition
[ https://issues.apache.org/jira/browse/HBASE-22310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827166#comment-16827166 ] Andrew Purtell commented on HBASE-22310: [~xucang] > checkAndMutate used an incorrect row to check the condition > --- > > Key: HBASE-22310 > URL: https://issues.apache.org/jira/browse/HBASE-22310 > Project: HBase > Issue Type: Bug > Components: API >Affects Versions: 1.3.3, 1.4.9 >Reporter: Adonis Ling >Assignee: Adonis Ling >Priority: Major > Attachments: HBASE-22310.branch-1.3.001.patch, > HBASE-22310.branch-1.3.002.patch, HBASE-22310.branch-1.4.001.patch, > HBASE-22310.branch-1.4.002.patch, HBASE-22310.branch-1.4.003.patch > > > In branch-1.4, checkAndMutate used the row of RowMutation to check the > condition which is incorrect. It will fail in the case which is checking a > row and mutate a different row. > The issue doesn't happen in the master branch. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22274) Cell size limit check on append should consider cell's previous size.
[
https://issues.apache.org/jira/browse/HBASE-22274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827156#comment-16827156
]
Xu Cang commented on HBASE-22274:
-
Agreed. [~apurtell]
I will investigate.
> Cell size limit check on append should consider cell's previous size.
> -
>
> Key: HBASE-22274
> URL: https://issues.apache.org/jira/browse/HBASE-22274
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 2.0.0, 1.3.5
>Reporter: Xu Cang
>Assignee: Xu Cang
>Priority: Minor
> Attachments: HBASE-22274-branch-1.001.patch,
> HBASE-22274-branch-1.002.patch, HBASE-22274-master.001.patch,
> HBASE-22274-master.002.patch, HBASE-22274-master.002.patch,
> HBASE-22274-master.003.patch
>
>
> Now we have cell size limit check based on this parameter
> *hbase.server.keyvalue.maxsize*
> One case was missing: appending to a cell only take append op's cell size
> into account against this limit check. we should check against the potential
> final cell size after the append.'
> It's easy to reproduce this :
>
> Apply this diff
>
> {code:java}
> diff --git
> a/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
>
> b/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
> index 5a285ef6ba..8633177ebe 100644 ---
> a/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
> +++
> b/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
> @@ -6455,7 +6455,7
> - t.append(new Append(ROW).addColumn(FAMILY, QUALIFIER, new byte[10 *
> 1024]));
> + t.append(new Append(ROW).addColumn(FAMILY, QUALIFIER, new byte[2 * 1024]));
> {code}
>
> Fix is to add this check in #reckonDeltas in HRegion class, where we have
> already got the appended cell's size.
> Will throw DoNotRetryIOException if checks is failed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-22301) Consider rolling the WAL if the HDFS write pipeline is slow
[ https://issues.apache.org/jira/browse/HBASE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827141#comment-16827141 ] Andrew Purtell edited comment on HBASE-22301 at 4/26/19 5:31 PM: - [~dmanning] It is possible there could be no writes for a long time, not very likely, but we can handle it. If we find that the difference between 'now' and the last time we triggered a roll is twice the monitoring interval when the count finally goes over threshold, we can reset the count instead of requesting a roll. This will prevent the corner case you describe. Regarding the default thresholds in this patch. I picked 10 slow syncs in one minute as a totally arbitrary choice so I could complete the change and get a patch up for consideration. Now let's discuss what should be reasonable defaults. Based on your analysis of our fleet under normal operation and with the default slow sync threshold of 100ms this change would result in: - If threshold is 10 slow syncs in 1 minute, we would request ~ 30,000 WAL rolls under normal operating conditions per day over on the order of 100 clusters. Load is distributed unevenly so dividing this number evenly by number of clusters doesn't make sense. This is more than we would want, I think. - If threshold is 200 slow syncs in 1 minute, we would request ~ 475 WAL rolls under normal operating conditions per day over on the order of 100 clusters. This would not be harmful. - During the incident that inspired this change, we had in excess of 500 slow sync warnings in one minute. As mentioned above, slow sync warnings can easily be false positives due to regionserver GC activity, which makes using them as signal problematic, but not unreasonable if we set the thresholds to sufficiently discriminate abnormal conditions. Also, bear in mind that under steady state writes we will frequently roll the log upon reaching the file size roll threshold anyway. False positive slow sync based rolls will be noise among this activity if we set the threshold right. Therefore, I think the next patch will have a default threshold of 100 slow syncs in one minute. Still kind of arbitrary, as defaults tend to be, but given the particular example of our production that would amount to ~950 rolls under normal operating conditions over 100 clusters in one day, but, in trade, it would trigger even if cluster is only under modest write load and would certainly have discriminated the HDFS level issues we encountered during our incident. was (Author: apurtell): [~dmanning] It is possible there could be no writes for a long time, not very likely, but we can handle it. If we find that the difference between 'now' and the last time we triggered a roll is twice the monitoring interval when the count finally goes over threshold, we can reset the count instead of requesting a roll. This will prevent the corner case you describe. Regarding the default thresholds in this patch. I picked 10 slow syncs in one minute as a totally arbitrary choice so I could complete the change and get a patch up for consideration. Now let's discuss what should be reasonable defaults. Based on your analysis of our fleet under normal operation this change would result in: - If threshold is 10 slow syncs in 1 minute, we would request ~ 30,000 WAL rolls under normal operating conditions per day over on the order of 100 clusters. Load is distributed unevenly so dividing this number evenly by number of clusters doesn't make sense. This is more than we would want, I think. - If threshold is 200 slow syncs in 1 minute, we would request ~ 475 WAL rolls under normal operating conditions per day over on the order of 100 clusters. This would not be harmful. - During the incident that inspired this change, we had in excess of 500 slow sync warnings in one minute. As mentioned above, slow sync warnings can easily be false positives due to regionserver GC activity, which makes using them as signal problematic, but not unreasonable if we set the thresholds to sufficiently discriminate abnormal conditions. Also, bear in mind that under steady state writes we will frequently roll the log upon reaching the file size roll threshold anyway. False positive slow sync based rolls will be noise among this activity if we set the threshold right. Therefore, I think the next patch will have a default threshold of 100 slow syncs in one minute. Still kind of arbitrary, as defaults tend to be, but given the particular example of our production that would amount to ~950 rolls under normal operating conditions over 100 clusters in one day, but, in trade, it would trigger even if cluster is only under modest write load and would certainly have discriminated the HDFS level issues we encountered during our incident. > Consider rolling the WAL if the HDFS write pipeline is slow >
[jira] [Commented] (HBASE-22301) Consider rolling the WAL if the HDFS write pipeline is slow
[ https://issues.apache.org/jira/browse/HBASE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827141#comment-16827141 ] Andrew Purtell commented on HBASE-22301: [~dmanning] It is possible there could be no writes for a long time, not very likely, but we can handle it. If we find that the difference between 'now' and the last time we triggered a roll is twice the monitoring interval when the count finally goes over threshold, we can reset the count instead of requesting a roll. This will prevent the corner case you describe. Regarding the default thresholds in this patch. I picked 10 slow syncs in one minute as a totally arbitrary choice so I could complete the change and get a patch up for consideration. Now let's discuss what should be reasonable defaults. Based on your analysis of our fleet under normal operation this change would result in: - If threshold is 10 slow syncs in 1 minute, we would request ~ 30,000 WAL rolls under normal operating conditions per day over on the order of 100 clusters. Load is distributed unevenly so dividing this number evenly by number of clusters doesn't make sense. This is more than we would want, I think. - If threshold is 200 slow syncs in 1 minute, we would request ~ 475 WAL rolls under normal operating conditions per day over on the order of 100 clusters. This would not be harmful. - During the incident that inspired this change, we had in excess of 500 slow sync warnings in one minute. As mentioned above, slow sync warnings can easily be false positives due to regionserver GC activity, which makes using them as signal problematic, but not unreasonable if we set the thresholds to sufficiently discriminate abnormal conditions. Also, bear in mind that under steady state writes we will frequently roll the log upon reaching the file size roll threshold anyway. False positive slow sync based rolls will be noise among this activity if we set the threshold right. Therefore, I think the next patch will have a default threshold of 100 slow syncs in one minute. Still kind of arbitrary, as defaults tend to be, but given the particular example of our production that would amount to ~950 rolls under normal operating conditions over 100 clusters in one day, but, in trade, it would trigger even if cluster is only under modest write load and would certainly have discriminated the HDFS level issues we encountered during our incident. > Consider rolling the WAL if the HDFS write pipeline is slow > --- > > Key: HBASE-22301 > URL: https://issues.apache.org/jira/browse/HBASE-22301 > Project: HBase > Issue Type: Improvement > Components: wal >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Fix For: 3.0.0, 1.5.0, 2.3.0 > > Attachments: HBASE-22301-branch-1.patch, HBASE-22301-branch-1.patch, > HBASE-22301-branch-1.patch > > > Consider the case when a subset of the HDFS fleet is unhealthy but suffering > a gray failure not an outright outage. HDFS operations, notably syncs, are > abnormally slow on pipelines which include this subset of hosts. If the > regionserver's WAL is backed by an impacted pipeline, all WAL handlers can be > consumed waiting for acks from the datanodes in the pipeline (recall that > some of them are sick). Imagine a write heavy application distributing load > uniformly over the cluster at a fairly high rate. With the WAL subsystem > slowed by HDFS level issues, all handlers can be blocked waiting to append to > the WAL. Once all handlers are blocked, the application will experience > backpressure. All (HBase) clients eventually have too many outstanding writes > and block. > Because the application is distributing writes near uniformly in the > keyspace, the probability any given service endpoint will dispatch a request > to an impacted regionserver, even a single regionserver, approaches 1.0. So > the probability that all service endpoints will be affected approaches 1.0. > In order to break the logjam, we need to remove the slow datanodes. Although > there is HDFS level monitoring, mechanisms, and procedures for this, we > should also attempt to take mitigating action at the HBase layer as soon as > we find ourselves in trouble. It would be enough to remove the affected > datanodes from the writer pipelines. A super simple strategy that can be > effective is described below: > This is with branch-1 code. I think branch-2's async WAL can mitigate but > still can be susceptible. branch-2 sync WAL is susceptible. > We already roll the WAL writer if the pipeline suffers the failure of a > datanode and the replication factor on the pipeline is too low. We should > also consider how much time it took for the write pipeline to complete a sync
[GitHub] [hbase-connectors] asfgit commented on issue #29: HBASE-22320 hbase-connectors personality skips non-scaladoc tests
asfgit commented on issue #29: HBASE-22320 hbase-connectors personality skips non-scaladoc tests URL: https://github.com/apache/hbase-connectors/pull/29#issuecomment-487132121 Refer to this link for build results (access rights to CI server needed): https://builds.apache.org/job/PreCommit-HBASE-CONNECTORS-Build/40/ 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-connectors] busbey opened a new pull request #29: HBASE-22320 hbase-connectors personality skips non-scaladoc tests
busbey opened a new pull request #29: HBASE-22320 hbase-connectors personality skips non-scaladoc tests URL: https://github.com/apache/hbase-connectors/pull/29 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-22318) Fix for warning The POM for org.glassfish:javax.el:jar is missing
[
https://issues.apache.org/jira/browse/HBASE-22318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Ervits updated HBASE-22318:
-
Status: Open (was: Patch Available)
> Fix for warning The POM for org.glassfish:javax.el:jar is missing
> -
>
> Key: HBASE-22318
> URL: https://issues.apache.org/jira/browse/HBASE-22318
> Project: HBase
> Issue Type: Task
> Components: hbase-connectors
>Affects Versions: connector-1.0.0
> Environment: {code:java}
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T14:33:14-04:00)
> Maven home: /opt/apache-maven-3.5.4
> Java version: 1.8.0_172, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"{code}
>Reporter: Artem Ervits
>Assignee: Artem Ervits
>Priority: Minor
> Fix For: connector-1.0.1
>
>
> {code:java}
> [WARNING] The POM for org.glassfish:javax.el:jar:3.0.1-b06-SNAPSHOT is
> missing, no dependency information available
> [WARNING] The POM for org.glassfish:javax.el:jar:3.0.1-b07-SNAPSHOT is
> missing, no dependency information available
> [WARNING] The POM for org.glassfish:javax.el:jar:3.0.1-b08-SNAPSHOT is
> missing, no dependency information available{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22318) Fix for warning The POM for org.glassfish:javax.el:jar is missing
[
https://issues.apache.org/jira/browse/HBASE-22318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Ervits updated HBASE-22318:
-
Attachment: (was: HBASE-22138.v01.patch)
> Fix for warning The POM for org.glassfish:javax.el:jar is missing
> -
>
> Key: HBASE-22318
> URL: https://issues.apache.org/jira/browse/HBASE-22318
> Project: HBase
> Issue Type: Task
> Components: hbase-connectors
>Affects Versions: connector-1.0.0
> Environment: {code:java}
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T14:33:14-04:00)
> Maven home: /opt/apache-maven-3.5.4
> Java version: 1.8.0_172, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"{code}
>Reporter: Artem Ervits
>Assignee: Artem Ervits
>Priority: Minor
> Fix For: connector-1.0.1
>
>
> {code:java}
> [WARNING] The POM for org.glassfish:javax.el:jar:3.0.1-b06-SNAPSHOT is
> missing, no dependency information available
> [WARNING] The POM for org.glassfish:javax.el:jar:3.0.1-b07-SNAPSHOT is
> missing, no dependency information available
> [WARNING] The POM for org.glassfish:javax.el:jar:3.0.1-b08-SNAPSHOT is
> missing, no dependency information available{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22318) Fix for warning The POM for org.glassfish:javax.el:jar is missing
[
https://issues.apache.org/jira/browse/HBASE-22318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Ervits updated HBASE-22318:
-
Affects Version/s: connector-1.0.0
> Fix for warning The POM for org.glassfish:javax.el:jar is missing
> -
>
> Key: HBASE-22318
> URL: https://issues.apache.org/jira/browse/HBASE-22318
> Project: HBase
> Issue Type: Task
> Components: hbase-connectors
>Affects Versions: connector-1.0.0
> Environment: {code:java}
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T14:33:14-04:00)
> Maven home: /opt/apache-maven-3.5.4
> Java version: 1.8.0_172, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"{code}
>Reporter: Artem Ervits
>Assignee: Artem Ervits
>Priority: Minor
> Attachments: HBASE-22138.v01.patch
>
>
> {code:java}
> [WARNING] The POM for org.glassfish:javax.el:jar:3.0.1-b06-SNAPSHOT is
> missing, no dependency information available
> [WARNING] The POM for org.glassfish:javax.el:jar:3.0.1-b07-SNAPSHOT is
> missing, no dependency information available
> [WARNING] The POM for org.glassfish:javax.el:jar:3.0.1-b08-SNAPSHOT is
> missing, no dependency information available{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22318) Fix for warning The POM for org.glassfish:javax.el:jar is missing
[
https://issues.apache.org/jira/browse/HBASE-22318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Ervits updated HBASE-22318:
-
Fix Version/s: connector-1.0.1
> Fix for warning The POM for org.glassfish:javax.el:jar is missing
> -
>
> Key: HBASE-22318
> URL: https://issues.apache.org/jira/browse/HBASE-22318
> Project: HBase
> Issue Type: Task
> Components: hbase-connectors
>Affects Versions: connector-1.0.0
> Environment: {code:java}
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T14:33:14-04:00)
> Maven home: /opt/apache-maven-3.5.4
> Java version: 1.8.0_172, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"{code}
>Reporter: Artem Ervits
>Assignee: Artem Ervits
>Priority: Minor
> Fix For: connector-1.0.1
>
> Attachments: HBASE-22138.v01.patch
>
>
> {code:java}
> [WARNING] The POM for org.glassfish:javax.el:jar:3.0.1-b06-SNAPSHOT is
> missing, no dependency information available
> [WARNING] The POM for org.glassfish:javax.el:jar:3.0.1-b07-SNAPSHOT is
> missing, no dependency information available
> [WARNING] The POM for org.glassfish:javax.el:jar:3.0.1-b08-SNAPSHOT is
> missing, no dependency information available{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22319) Fix for warning The assembly descriptor contains a filesystem-root relative reference
[
https://issues.apache.org/jira/browse/HBASE-22319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi updated HBASE-22319:
--
Affects Version/s: connector-1.0.0
> Fix for warning The assembly descriptor contains a filesystem-root relative
> reference
> -
>
> Key: HBASE-22319
> URL: https://issues.apache.org/jira/browse/HBASE-22319
> Project: HBase
> Issue Type: Bug
> Components: hbase-connectors
>Affects Versions: connector-1.0.0
> Environment: {code:java}
> Maven home: /opt/apache-maven-3.5.4
> Java version: 1.8.0_172, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"{code}
>Reporter: Artem Ervits
>Assignee: Artem Ervits
>Priority: Minor
> Fix For: connector-1.0.1
>
>
> {code:java}
> [INFO] Reading assembly descriptor: src/main/assembly/hbase-connectors-bin.xml
> [WARNING] The assembly descriptor contains a filesystem-root relative
> reference, which is not cross platform compatible /
> [WARNING] The assembly descriptor contains a filesystem-root relative
> reference, which is not cross platform compatible /{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22319) Fix for warning The assembly descriptor contains a filesystem-root relative reference
[
https://issues.apache.org/jira/browse/HBASE-22319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi updated HBASE-22319:
--
Fix Version/s: connector-1.0.1
> Fix for warning The assembly descriptor contains a filesystem-root relative
> reference
> -
>
> Key: HBASE-22319
> URL: https://issues.apache.org/jira/browse/HBASE-22319
> Project: HBase
> Issue Type: Bug
> Components: hbase-connectors
> Environment: {code:java}
> Maven home: /opt/apache-maven-3.5.4
> Java version: 1.8.0_172, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"{code}
>Reporter: Artem Ervits
>Assignee: Artem Ervits
>Priority: Minor
> Fix For: connector-1.0.1
>
>
> {code:java}
> [INFO] Reading assembly descriptor: src/main/assembly/hbase-connectors-bin.xml
> [WARNING] The assembly descriptor contains a filesystem-root relative
> reference, which is not cross platform compatible /
> [WARNING] The assembly descriptor contains a filesystem-root relative
> reference, which is not cross platform compatible /{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
