[jira] [Commented] (HBASE-17668) Implement async assgin/offline/move/unassign methods
[
https://issues.apache.org/jira/browse/HBASE-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948444#comment-15948444
]
Hadoop QA commented on HBASE-17668:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 18s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 27s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
39s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 1s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
25s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
58s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 54s
{color} | {color:green} master passed {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
15s {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 {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
53s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
26s {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} hadoopcheck {color} | {color:green}
31m 28s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 27s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 115m 50s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
41s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 169m 36s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12861147/HBASE-17668.v2.patch |
| JIRA Issue | HBASE-17668 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux d31368f2b0b3 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / b290d14 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6263/testReport/ |
| modules | C: hbase-client hbase-server U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6263/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Implement async assgin/offline/move/unassign
[jira] [Commented] (HBASE-17816) HRegion#mutateRowWithLocks should update writeRequestCount metric
[
https://issues.apache.org/jira/browse/HBASE-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948415#comment-15948415
]
Hadoop QA commented on HBASE-17816:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
5s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 48s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
19s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
59s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
55s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {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} hadoopcheck {color} | {color:green}
35m 41s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 128m 19s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
18s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 179m 58s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestHRegion |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12859808/HBASE-17816.master.001.patch
|
| JIRA Issue | HBASE-17816 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 70d504b0efee 3.13.0-105-generic #152-Ubuntu SMP Fri Dec 2
15:37:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / b290d14 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/6261/artifact/patchprocess/patch-unit-hbase-server.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/6261/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6261/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6261/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
>
[jira] [Updated] (HBASE-17816) HRegion#mutateRowWithLocks should update writeRequestCount metric
[ https://issues.apache.org/jira/browse/HBASE-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-17816: Status: Patch Available (was: Open) > HRegion#mutateRowWithLocks should update writeRequestCount metric > - > > Key: HBASE-17816 > URL: https://issues.apache.org/jira/browse/HBASE-17816 > Project: HBase > Issue Type: Bug > Components: metrics >Reporter: Ashu Pachauri >Assignee: Weizhan Zeng > Attachments: HBASE-17816.master.001.patch, > HBASE-17816.master.002.patch > > > Currently, all the calls that use HRegion#mutateRowWithLocks miss > writeRequestCount metric. The mutateRowWithLocks base method should update > the metric. > Examples are checkAndMutate calls through RSRpcServices#multi, > Region#mutateRow api , MultiRowMutationProcessor coprocessor endpoint. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17816) HRegion#mutateRowWithLocks should update writeRequestCount metric
[ https://issues.apache.org/jira/browse/HBASE-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-17816: Component/s: metrics > HRegion#mutateRowWithLocks should update writeRequestCount metric > - > > Key: HBASE-17816 > URL: https://issues.apache.org/jira/browse/HBASE-17816 > Project: HBase > Issue Type: Bug > Components: metrics >Reporter: Ashu Pachauri >Assignee: Weizhan Zeng > Attachments: HBASE-17816.master.001.patch, > HBASE-17816.master.002.patch > > > Currently, all the calls that use HRegion#mutateRowWithLocks miss > writeRequestCount metric. The mutateRowWithLocks base method should update > the metric. > Examples are checkAndMutate calls through RSRpcServices#multi, > Region#mutateRow api , MultiRowMutationProcessor coprocessor endpoint. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17215) Separate small/large file delete threads in HFileCleaner to accelerate archived hfile cleanup speed
[
https://issues.apache.org/jira/browse/HBASE-17215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948406#comment-15948406
]
Ted Yu commented on HBASE-17215:
Since this has been verified in production, I am fine with getting it in after
addressing other review comments.
But I feel hfile cleaning is different from compaction in that cleaning up
large files would free up disk space more quickly.
This can be done in a follow-up issue.
> Separate small/large file delete threads in HFileCleaner to accelerate
> archived hfile cleanup speed
> ---
>
> Key: HBASE-17215
> URL: https://issues.apache.org/jira/browse/HBASE-17215
> Project: HBase
> Issue Type: Improvement
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-17215.patch
>
>
> When using PCIe-SSD the flush speed will be really quick, and although we
> have per CF flush, we still have the
> {{hbase.regionserver.optionalcacheflushinterval}} setting and some other
> mechanism to avoid data kept in memory for too long to flush small hfiles. In
> our online environment we found the single thread cleaner kept cleaning
> earlier flushed small files while large files got no chance, which caused
> disk full then many other problems.
> Deleting hfiles in parallel with too many threads will also increase the
> workload of namenode, so here we propose to separate large/small hfile
> cleaner threads just like we do for compaction, and it turned out to work
> well in our cluster.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17215) Separate small/large file delete threads in HFileCleaner to accelerate archived hfile cleanup speed
[
https://issues.apache.org/jira/browse/HBASE-17215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948399#comment-15948399
]
Yu Li commented on HBASE-17215:
---
bq. hbase.hfile.compaction.discharger.interval default to be lowered in ur view?
I'm not sure, since this {{hbase.hfile.compaction.discharger.interval}} is on
regionserver-side while {{hbase.master.cleaner.interval}} on master side.
Considering multiple RS archiving files, I think master should have a higher
rate. Wdyt? [~anoop.hbase]
bq. This is not PCIe-SSD, for some reason that in archive...
I'm very much interested in this "some reason" (smile). Ever dig into it and
mind share if so? Thanks. [~huaxiang]
bq. I was thinking why would a thread be dedicated to cleaning up small files?
I simply borrowed the idea from compaction, where we have different threads
dealing with different size. And there're more small hfiles than large ones in
common case, which also likes the case in compaction. In our case the root
cause of the issue was (truly) too many small files blocked large file deletion
thus slowed down the disk space free up, but is it possible that too many large
files blocking small ones although corner case? [~tedyu]
bq. can these two threads share a LinkedBlockingDeque?
Yes, we could use {{StealJobQueue}} directly referring to compaction, but mind
if I open another thread to do this improvement? The current implementation has
been verified online so I'm more sure about its stability. [~huaxiang]
> Separate small/large file delete threads in HFileCleaner to accelerate
> archived hfile cleanup speed
> ---
>
> Key: HBASE-17215
> URL: https://issues.apache.org/jira/browse/HBASE-17215
> Project: HBase
> Issue Type: Improvement
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-17215.patch
>
>
> When using PCIe-SSD the flush speed will be really quick, and although we
> have per CF flush, we still have the
> {{hbase.regionserver.optionalcacheflushinterval}} setting and some other
> mechanism to avoid data kept in memory for too long to flush small hfiles. In
> our online environment we found the single thread cleaner kept cleaning
> earlier flushed small files while large files got no chance, which caused
> disk full then many other problems.
> Deleting hfiles in parallel with too many threads will also increase the
> workload of namenode, so here we propose to separate large/small hfile
> cleaner threads just like we do for compaction, and it turned out to work
> well in our cluster.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17520) Implement isTableEnabled/Disabled/Available methods
[ https://issues.apache.org/jira/browse/HBASE-17520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948392#comment-15948392 ] Duo Zhang commented on HBASE-17520: --- +1. > Implement isTableEnabled/Disabled/Available methods > --- > > Key: HBASE-17520 > URL: https://issues.apache.org/jira/browse/HBASE-17520 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17520-v1.patch, HBASE-17520-v2.patch, > HBASE-17520-v3.patch, HBASE-17520-v4.patch, HBASE-17520-v5.patch, > HBASE-17520-v6.patch, HBASE-17520-v6.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17520) Implement isTableEnabled/Disabled/Available methods
[
https://issues.apache.org/jira/browse/HBASE-17520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948384#comment-15948384
]
Hadoop QA commented on HBASE-17520:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 18s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 27s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
23s {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} 0m
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
23s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
33s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 43s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
59s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 53s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 53s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
23s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 22s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
48s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 43s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 7s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 100m 24s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
31s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 146m 57s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12861140/HBASE-17520-v6.patch |
| JIRA Issue | HBASE-17520 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 767498bdfb45 3.13.0-103-generic #150-Ubuntu SMP Thu Nov 24
10:34:17 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / b290d14 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6262/testReport/ |
| modules | C: hbase-client hbase-server U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6262/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Implement isTableEnabled/Disabled/Available
[jira] [Commented] (HBASE-17844) Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical related changes)
[
https://issues.apache.org/jira/browse/HBASE-17844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948337#comment-15948337
]
Hadoop QA commented on HBASE-17844:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 49s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 9 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 30s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 46s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
47s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
1s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
32s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 33s
{color} | {color:green} master passed {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
57s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 46s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
0s {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} hadoopcheck {color} | {color:green}
32m 2s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
23s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 57s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 51s
{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 23s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 113m 39s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 9s
{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
14s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 188m 4s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12861121/HBASE-17844.master.003.patch
|
| JIRA Issue | HBASE-17844 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 06c9e4a1ea6b 3.13.0-105-generic #152-Ubuntu SMP Fri Dec 2
15:37:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master /
[jira] [Commented] (HBASE-17844) Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical related changes)
[ https://issues.apache.org/jira/browse/HBASE-17844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948338#comment-15948338 ] stack commented on HBASE-17844: --- .004 addresses @appy review up on rb. > Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical > related changes) > --- > > Key: HBASE-17844 > URL: https://issues.apache.org/jira/browse/HBASE-17844 > Project: HBase > Issue Type: Bug > Components: Region Assignment >Affects Versions: 2.0.0 >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-17844.master.001.patch, > HBASE-17844.master.002.patch, HBASE-17844.master.003.patch, > HBASE-17844.master.004.patch > > > Here is a patch that breaks out non-pertinent changes that made it into > HBASE-14614 in an attempt at shrinking its overall size. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Work stopped] (HBASE-17816) HRegion#mutateRowWithLocks should update writeRequestCount metric
[ https://issues.apache.org/jira/browse/HBASE-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-17816 stopped by Weizhan Zeng. > HRegion#mutateRowWithLocks should update writeRequestCount metric > - > > Key: HBASE-17816 > URL: https://issues.apache.org/jira/browse/HBASE-17816 > Project: HBase > Issue Type: Bug >Reporter: Ashu Pachauri >Assignee: Weizhan Zeng > Attachments: HBASE-17816.master.001.patch, > HBASE-17816.master.002.patch > > > Currently, all the calls that use HRegion#mutateRowWithLocks miss > writeRequestCount metric. The mutateRowWithLocks base method should update > the metric. > Examples are checkAndMutate calls through RSRpcServices#multi, > Region#mutateRow api , MultiRowMutationProcessor coprocessor endpoint. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17844) Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical related changes)
[ https://issues.apache.org/jira/browse/HBASE-17844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17844: -- Attachment: HBASE-17844.master.004.patch > Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical > related changes) > --- > > Key: HBASE-17844 > URL: https://issues.apache.org/jira/browse/HBASE-17844 > Project: HBase > Issue Type: Bug > Components: Region Assignment >Affects Versions: 2.0.0 >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-17844.master.001.patch, > HBASE-17844.master.002.patch, HBASE-17844.master.003.patch, > HBASE-17844.master.004.patch > > > Here is a patch that breaks out non-pertinent changes that made it into > HBASE-14614 in an attempt at shrinking its overall size. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17816) HRegion#mutateRowWithLocks should update writeRequestCount metric
[ https://issues.apache.org/jira/browse/HBASE-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-17816: Status: In Progress (was: Patch Available) oh okay. the precommit bot will happily check against a github PR; I was just getting it going. > HRegion#mutateRowWithLocks should update writeRequestCount metric > - > > Key: HBASE-17816 > URL: https://issues.apache.org/jira/browse/HBASE-17816 > Project: HBase > Issue Type: Bug >Reporter: Ashu Pachauri >Assignee: Weizhan Zeng > Attachments: HBASE-17816.master.001.patch, > HBASE-17816.master.002.patch > > > Currently, all the calls that use HRegion#mutateRowWithLocks miss > writeRequestCount metric. The mutateRowWithLocks base method should update > the metric. > Examples are checkAndMutate calls through RSRpcServices#multi, > Region#mutateRow api , MultiRowMutationProcessor coprocessor endpoint. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17816) HRegion#mutateRowWithLocks should update writeRequestCount metric
[ https://issues.apache.org/jira/browse/HBASE-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948315#comment-15948315 ] Sean Busbey commented on HBASE-17816: - sorry! I missed the patch attached here. Can you switch the jira back to patch available? > HRegion#mutateRowWithLocks should update writeRequestCount metric > - > > Key: HBASE-17816 > URL: https://issues.apache.org/jira/browse/HBASE-17816 > Project: HBase > Issue Type: Bug >Reporter: Ashu Pachauri >Assignee: Weizhan Zeng > Attachments: HBASE-17816.master.001.patch, > HBASE-17816.master.002.patch > > > Currently, all the calls that use HRegion#mutateRowWithLocks miss > writeRequestCount metric. The mutateRowWithLocks base method should update > the metric. > Examples are checkAndMutate calls through RSRpcServices#multi, > Region#mutateRow api , MultiRowMutationProcessor coprocessor endpoint. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17816) HRegion#mutateRowWithLocks should update writeRequestCount metric
[ https://issues.apache.org/jira/browse/HBASE-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Weizhan Zeng updated HBASE-17816: - Attachment: HBASE-17816.master.002.patch I add a test TestHRegion#testMutateRow_WriteRequestCount , can you help review it is ok ? > HRegion#mutateRowWithLocks should update writeRequestCount metric > - > > Key: HBASE-17816 > URL: https://issues.apache.org/jira/browse/HBASE-17816 > Project: HBase > Issue Type: Bug >Reporter: Ashu Pachauri >Assignee: Weizhan Zeng > Attachments: HBASE-17816.master.001.patch, > HBASE-17816.master.002.patch > > > Currently, all the calls that use HRegion#mutateRowWithLocks miss > writeRequestCount metric. The mutateRowWithLocks base method should update > the metric. > Examples are checkAndMutate calls through RSRpcServices#multi, > Region#mutateRow api , MultiRowMutationProcessor coprocessor endpoint. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17668) Implement async assgin/offline/move/unassign methods
[ https://issues.apache.org/jira/browse/HBASE-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-17668: - Attachment: HBASE-17668.v2.patch Patch v2: 1. use Bytes.toBytes() instead of String.getBytes(). 2. use async moveRegion for unit test. > Implement async assgin/offline/move/unassign methods > > > Key: HBASE-17668 > URL: https://issues.apache.org/jira/browse/HBASE-17668 > Project: HBase > Issue Type: Sub-task > Components: Admin, asyncclient, Client >Affects Versions: 2.0.0 >Reporter: Zheng Hu >Assignee: Zheng Hu > Fix For: 2.0.0 > > Attachments: HBASE-17668.v1.patch, HBASE-17668.v1.patch, > HBASE-17668.v2.patch > > > Implement following methods for async admin client: > 1. assign region; > 2. unassign region; > 3. offline region; > 4. move region; -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17215) Separate small/large file delete threads in HFileCleaner to accelerate archived hfile cleanup speed
[
https://issues.apache.org/jira/browse/HBASE-17215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948294#comment-15948294
]
Ted Yu commented on HBASE-17215:
I was thinking why would a thread be dedicated to cleaning up small files ?
Considering that cleaning up the largest files first would be more economical.
Can the two threads be taking turns to clean up the largest files ?
> Separate small/large file delete threads in HFileCleaner to accelerate
> archived hfile cleanup speed
> ---
>
> Key: HBASE-17215
> URL: https://issues.apache.org/jira/browse/HBASE-17215
> Project: HBase
> Issue Type: Improvement
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-17215.patch
>
>
> When using PCIe-SSD the flush speed will be really quick, and although we
> have per CF flush, we still have the
> {{hbase.regionserver.optionalcacheflushinterval}} setting and some other
> mechanism to avoid data kept in memory for too long to flush small hfiles. In
> our online environment we found the single thread cleaner kept cleaning
> earlier flushed small files while large files got no chance, which caused
> disk full then many other problems.
> Deleting hfiles in parallel with too many threads will also increase the
> workload of namenode, so here we propose to separate large/small hfile
> cleaner threads just like we do for compaction, and it turned out to work
> well in our cluster.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17816) HRegion#mutateRowWithLocks should update writeRequestCount metric
[ https://issues.apache.org/jira/browse/HBASE-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948280#comment-15948280 ] Weizhan Zeng commented on HBASE-17816: -- [~busbey] I had closed it! > HRegion#mutateRowWithLocks should update writeRequestCount metric > - > > Key: HBASE-17816 > URL: https://issues.apache.org/jira/browse/HBASE-17816 > Project: HBase > Issue Type: Bug >Reporter: Ashu Pachauri >Assignee: Weizhan Zeng > Attachments: HBASE-17816.master.001.patch > > > Currently, all the calls that use HRegion#mutateRowWithLocks miss > writeRequestCount metric. The mutateRowWithLocks base method should update > the metric. > Examples are checkAndMutate calls through RSRpcServices#multi, > Region#mutateRow api , MultiRowMutationProcessor coprocessor endpoint. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-17215) Separate small/large file delete threads in HFileCleaner to accelerate archived hfile cleanup speed
[
https://issues.apache.org/jira/browse/HBASE-17215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948201#comment-15948201
]
huaxiang sun edited comment on HBASE-17215 at 3/30/17 1:57 AM:
---
Thanks [~carp84] for the patch! The patch looks great. I went through the patch
and left couple comments there. Maybe as a followup, can these two threads
share a LinkedBlockingDeque? So large-size file is added to the head of the
queue and small-size files are added to the tail. the large-file-thread poll
from the head and the small-file-thread poll from the end. In this sense, no
thread will be idle when there are works to do. What do you think?
Or we do sorting of filesToBeDeleted based on the file size, push into the
queue with largest size files first. These two threads can poll files out of
the queue. Essentially, these two threads will delete files from large size to
small size.
was (Author: huaxiang):
Thanks [~carp84] for the patch! The patch looks great. I went through the patch
and left couple comments there. Maybe as a followup, can these two threads
share a LinkedBlockingDeque? So large-size file is added to the head of the
queue and small-size files are added to the tail. the large-file-thread poll
from the head and the small-file-thread poll from the end. In this sense, no
thread will be idle when there are works to do. What do you think?
> Separate small/large file delete threads in HFileCleaner to accelerate
> archived hfile cleanup speed
> ---
>
> Key: HBASE-17215
> URL: https://issues.apache.org/jira/browse/HBASE-17215
> Project: HBase
> Issue Type: Improvement
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-17215.patch
>
>
> When using PCIe-SSD the flush speed will be really quick, and although we
> have per CF flush, we still have the
> {{hbase.regionserver.optionalcacheflushinterval}} setting and some other
> mechanism to avoid data kept in memory for too long to flush small hfiles. In
> our online environment we found the single thread cleaner kept cleaning
> earlier flushed small files while large files got no chance, which caused
> disk full then many other problems.
> Deleting hfiles in parallel with too many threads will also increase the
> workload of namenode, so here we propose to separate large/small hfile
> cleaner threads just like we do for compaction, and it turned out to work
> well in our cluster.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17816) HRegion#mutateRowWithLocks should update writeRequestCount metric
[ https://issues.apache.org/jira/browse/HBASE-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948237#comment-15948237 ] Sean Busbey commented on HBASE-17816: - https://github.com/apache/hbase/pull/46 > HRegion#mutateRowWithLocks should update writeRequestCount metric > - > > Key: HBASE-17816 > URL: https://issues.apache.org/jira/browse/HBASE-17816 > Project: HBase > Issue Type: Bug >Reporter: Ashu Pachauri >Assignee: Weizhan Zeng > Attachments: HBASE-17816.master.001.patch > > > Currently, all the calls that use HRegion#mutateRowWithLocks miss > writeRequestCount metric. The mutateRowWithLocks base method should update > the metric. > Examples are checkAndMutate calls through RSRpcServices#multi, > Region#mutateRow api , MultiRowMutationProcessor coprocessor endpoint. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17816) HRegion#mutateRowWithLocks should update writeRequestCount metric
[ https://issues.apache.org/jira/browse/HBASE-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-17816: Status: Patch Available (was: Open) > HRegion#mutateRowWithLocks should update writeRequestCount metric > - > > Key: HBASE-17816 > URL: https://issues.apache.org/jira/browse/HBASE-17816 > Project: HBase > Issue Type: Bug >Reporter: Ashu Pachauri >Assignee: Weizhan Zeng > Attachments: HBASE-17816.master.001.patch > > > Currently, all the calls that use HRegion#mutateRowWithLocks miss > writeRequestCount metric. The mutateRowWithLocks base method should update > the metric. > Examples are checkAndMutate calls through RSRpcServices#multi, > Region#mutateRow api , MultiRowMutationProcessor coprocessor endpoint. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17520) Implement isTableEnabled/Disabled/Available methods
[ https://issues.apache.org/jira/browse/HBASE-17520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-17520: --- Attachment: HBASE-17520-v6.patch Try to trigger Hadoop QA again. > Implement isTableEnabled/Disabled/Available methods > --- > > Key: HBASE-17520 > URL: https://issues.apache.org/jira/browse/HBASE-17520 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0 > > Attachments: HBASE-17520-v1.patch, HBASE-17520-v2.patch, > HBASE-17520-v3.patch, HBASE-17520-v4.patch, HBASE-17520-v5.patch, > HBASE-17520-v6.patch, HBASE-17520-v6.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17215) Separate small/large file delete threads in HFileCleaner to accelerate archived hfile cleanup speed
[
https://issues.apache.org/jira/browse/HBASE-17215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948201#comment-15948201
]
huaxiang sun commented on HBASE-17215:
--
Thanks [~carp84] for the patch! The patch looks great. I went through the patch
and left couple comments there. Maybe as a followup, can these two threads
share a LinkedBlockingDeque? So large-size file is added to the head of the
queue and small-size files are added to the tail. the large-file-thread poll
from the head and the small-file-thread poll from the end. In this sense, no
thread will be idle when there are works to do. What do you think?
> Separate small/large file delete threads in HFileCleaner to accelerate
> archived hfile cleanup speed
> ---
>
> Key: HBASE-17215
> URL: https://issues.apache.org/jira/browse/HBASE-17215
> Project: HBase
> Issue Type: Improvement
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-17215.patch
>
>
> When using PCIe-SSD the flush speed will be really quick, and although we
> have per CF flush, we still have the
> {{hbase.regionserver.optionalcacheflushinterval}} setting and some other
> mechanism to avoid data kept in memory for too long to flush small hfiles. In
> our online environment we found the single thread cleaner kept cleaning
> earlier flushed small files while large files got no chance, which caused
> disk full then many other problems.
> Deleting hfiles in parallel with too many threads will also increase the
> workload of namenode, so here we propose to separate large/small hfile
> cleaner threads just like we do for compaction, and it turned out to work
> well in our cluster.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (HBASE-17847) update documentation to include positions on recent Hadoop releases
[ https://issues.apache.org/jira/browse/HBASE-17847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey resolved HBASE-17847. - Resolution: Fixed thanks for the reviews, this is live now. > update documentation to include positions on recent Hadoop releases > --- > > Key: HBASE-17847 > URL: https://issues.apache.org/jira/browse/HBASE-17847 > Project: HBase > Issue Type: Task > Components: community, documentation >Affects Versions: 2.0.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-17847.0.patch, HBASE-17847.1.patch > > > [per dev@hbase discussion on how to handle the most recent round of Hadoop > releases|https://lists.apache.org/thread.html/bb5591e3260f4e70d40c1f9cb30aa98d018fc145ab3aef8b3f6a4f5d@%3Cdev.hbase.apache.org%3E], > get our docs updated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17847) update documentation to include positions on recent Hadoop releases
[ https://issues.apache.org/jira/browse/HBASE-17847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948148#comment-15948148 ] Hudson commented on HBASE-17847: SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2764 (See [https://builds.apache.org/job/HBase-Trunk_matrix/2764/]) HBASE-17847 update docs to cover guidance on recent Hadoop releases. (busbey: rev b290d14e1f7fffa3c06bb19770b53094c3d2459a) * (edit) src/main/asciidoc/_chapters/configuration.adoc > update documentation to include positions on recent Hadoop releases > --- > > Key: HBASE-17847 > URL: https://issues.apache.org/jira/browse/HBASE-17847 > Project: HBase > Issue Type: Task > Components: community, documentation >Affects Versions: 2.0.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-17847.0.patch, HBASE-17847.1.patch > > > [per dev@hbase discussion on how to handle the most recent round of Hadoop > releases|https://lists.apache.org/thread.html/bb5591e3260f4e70d40c1f9cb30aa98d018fc145ab3aef8b3f6a4f5d@%3Cdev.hbase.apache.org%3E], > get our docs updated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-16573) Backup restore into disabled table support
[
https://issues.apache.org/jira/browse/HBASE-16573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-16573:
--
Fix Version/s: (was: HBASE-7912)
2.0.0
> Backup restore into disabled table support
> --
>
> Key: HBASE-16573
> URL: https://issues.apache.org/jira/browse/HBASE-16573
> Project: HBase
> Issue Type: Bug
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Labels: backup
> Fix For: 2.0.0
>
>
> If we restore into existing table, table must be disabled to avoid and block
> any incoming requests.
> {code}
> java.lang.IllegalStateException: Cannot restore hbase table
> at
> org.apache.hadoop.hbase.backup.util.RestoreServerUtil.restoreTableAndCreate(RestoreServerUtil.java:492)
> at
> org.apache.hadoop.hbase.backup.util.RestoreServerUtil.fullRestoreTable(RestoreServerUtil.java:264)
> at
> org.apache.hadoop.hbase.backup.impl.RestoreClientImpl.restoreImages(RestoreClientImpl.java:321)
> at
> org.apache.hadoop.hbase.backup.impl.RestoreClientImpl.restore(RestoreClientImpl.java:219)
> at
> org.apache.hadoop.hbase.backup.impl.RestoreClientImpl.restore(RestoreClientImpl.java:107)
> at
> org.apache.hadoop.hbase.client.HBaseBackupAdmin.restore(HBaseBackupAdmin.java:411)
> at
> org.apache.hadoop.hbase.backup.TestIncrementalBackup.TestIncBackupRestore(TestIncrementalBackup.java:171)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> Caused by: org.apache.hadoop.hbase.TableNotFoundException: Table
> ns1:table1_restore is not currently available.
> at
> org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles.doBulkLoad(LoadIncrementalHFiles.java:347)
> at
> org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles.run(LoadIncrementalHFiles.java:1097)
> at
> org.apache.hadoop.hbase.backup.util.RestoreServerUtil.restoreTableAndCreate(RestoreServerUtil.java:487)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-15993) Regex support in table names
[ https://issues.apache.org/jira/browse/HBASE-15993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-15993: -- Fix Version/s: (was: HBASE-7912) 2.0.0 > Regex support in table names > > > Key: HBASE-15993 > URL: https://issues.apache.org/jira/browse/HBASE-15993 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov > Labels: backup > Fix For: 2.0.0 > > > Add support for regular expression in table names in backup/restore/set > operations. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-16573) Backup restore into disabled table support
[
https://issues.apache.org/jira/browse/HBASE-16573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-16573:
--
Labels: backup (was: )
> Backup restore into disabled table support
> --
>
> Key: HBASE-16573
> URL: https://issues.apache.org/jira/browse/HBASE-16573
> Project: HBase
> Issue Type: Bug
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Labels: backup
> Fix For: 2.0.0
>
>
> If we restore into existing table, table must be disabled to avoid and block
> any incoming requests.
> {code}
> java.lang.IllegalStateException: Cannot restore hbase table
> at
> org.apache.hadoop.hbase.backup.util.RestoreServerUtil.restoreTableAndCreate(RestoreServerUtil.java:492)
> at
> org.apache.hadoop.hbase.backup.util.RestoreServerUtil.fullRestoreTable(RestoreServerUtil.java:264)
> at
> org.apache.hadoop.hbase.backup.impl.RestoreClientImpl.restoreImages(RestoreClientImpl.java:321)
> at
> org.apache.hadoop.hbase.backup.impl.RestoreClientImpl.restore(RestoreClientImpl.java:219)
> at
> org.apache.hadoop.hbase.backup.impl.RestoreClientImpl.restore(RestoreClientImpl.java:107)
> at
> org.apache.hadoop.hbase.client.HBaseBackupAdmin.restore(HBaseBackupAdmin.java:411)
> at
> org.apache.hadoop.hbase.backup.TestIncrementalBackup.TestIncBackupRestore(TestIncrementalBackup.java:171)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> Caused by: org.apache.hadoop.hbase.TableNotFoundException: Table
> ns1:table1_restore is not currently available.
> at
> org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles.doBulkLoad(LoadIncrementalHFiles.java:347)
> at
> org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles.run(LoadIncrementalHFiles.java:1097)
> at
> org.apache.hadoop.hbase.backup.util.RestoreServerUtil.restoreTableAndCreate(RestoreServerUtil.java:487)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-16673) Enhance history command: history per backup set
[ https://issues.apache.org/jira/browse/HBASE-16673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16673: -- Fix Version/s: (was: HBASE-7912) 2.0.0 > Enhance history command: history per backup set > --- > > Key: HBASE-16673 > URL: https://issues.apache.org/jira/browse/HBASE-16673 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-16673-v1.patch, HBASE-16673-v2.patch > > > New command-line option: -set setName. Will retrieve backup history for a > particular backup set -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-16673) Enhance history command: history per backup set
[ https://issues.apache.org/jira/browse/HBASE-16673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16673: -- Labels: backup (was: ) > Enhance history command: history per backup set > --- > > Key: HBASE-16673 > URL: https://issues.apache.org/jira/browse/HBASE-16673 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-16673-v1.patch, HBASE-16673-v2.patch > > > New command-line option: -set setName. Will retrieve backup history for a > particular backup set -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17133) Backup documentation update
[
https://issues.apache.org/jira/browse/HBASE-17133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-17133:
--
Labels: backup (was: )
> Backup documentation update
> ---
>
> Key: HBASE-17133
> URL: https://issues.apache.org/jira/browse/HBASE-17133
> Project: HBase
> Issue Type: Bug
>Reporter: Vladimir Rodionov
>Priority: Blocker
> Labels: backup
> Fix For: 2.0.0
>
>
> We need to update backup doc to sync it with the current implementation and
> to add section for current limitations:
> {quote}
> - if you write to the table with Durability.SKIP_WALS your data will not
> be in the incremental-backup
> - if you bulkload files that data will not be in the incremental backup
> (HBASE-14417)
> - the incremental backup will not only contains the data of the table you
> specified but also the regions from other tables that are on the same set
> of RSs (HBASE-14141) ...maybe a note about security around this topic
> - the incremental backup will not contains just the "latest row" between
> backup A and B, but it will also contains all the updates occurred in
> between. but the restore does not allow you to restore up to a certain
> point in time, the restore will always be up to the "latest backup point".
> - you should limit the number of "incremental" up to N (or maybe SIZE), to
> avoid replay time becoming the bottleneck. (HBASE-14135)
> {quote}
> Update command line tool section
> Clarify restore backup section
> Add section on backup delete algorithm
> Add section on how backup image dependency chain works.
> Add section for configuration
> hbase.backup.enable=true
> hbase.master.logcleaner.plugins=YOUR_PUGINS,org.apache.hadoop.hbase.backup.master.BackupLogCleaner
> hbase.procedure.master.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureManager
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17133) Backup documentation update
[
https://issues.apache.org/jira/browse/HBASE-17133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-17133:
--
Fix Version/s: (was: HBASE-7912)
2.0.0
> Backup documentation update
> ---
>
> Key: HBASE-17133
> URL: https://issues.apache.org/jira/browse/HBASE-17133
> Project: HBase
> Issue Type: Bug
>Reporter: Vladimir Rodionov
>Priority: Blocker
> Labels: backup
> Fix For: 2.0.0
>
>
> We need to update backup doc to sync it with the current implementation and
> to add section for current limitations:
> {quote}
> - if you write to the table with Durability.SKIP_WALS your data will not
> be in the incremental-backup
> - if you bulkload files that data will not be in the incremental backup
> (HBASE-14417)
> - the incremental backup will not only contains the data of the table you
> specified but also the regions from other tables that are on the same set
> of RSs (HBASE-14141) ...maybe a note about security around this topic
> - the incremental backup will not contains just the "latest row" between
> backup A and B, but it will also contains all the updates occurred in
> between. but the restore does not allow you to restore up to a certain
> point in time, the restore will always be up to the "latest backup point".
> - you should limit the number of "incremental" up to N (or maybe SIZE), to
> avoid replay time becoming the bottleneck. (HBASE-14135)
> {quote}
> Update command line tool section
> Clarify restore backup section
> Add section on backup delete algorithm
> Add section on how backup image dependency chain works.
> Add section for configuration
> hbase.backup.enable=true
> hbase.master.logcleaner.plugins=YOUR_PUGINS,org.apache.hadoop.hbase.backup.master.BackupLogCleaner
> hbase.procedure.master.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureManager
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-16181) Allow snapshot of hbase:backup table
[ https://issues.apache.org/jira/browse/HBASE-16181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16181: -- Fix Version/s: (was: HBASE-7912) 2.0.0 > Allow snapshot of hbase:backup table > > > Key: HBASE-16181 > URL: https://issues.apache.org/jira/browse/HBASE-16181 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-16181-v1.patch, HBASE-16181-v2.patch > > > Snapshot of HBase system tables is not supported, we need either move > hbase:backup into different name space or fix snapshots. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-16656) BackupID must include backup set name
[ https://issues.apache.org/jira/browse/HBASE-16656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16656: -- Labels: backup (was: ) > BackupID must include backup set name > - > > Key: HBASE-16656 > URL: https://issues.apache.org/jira/browse/HBASE-16656 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-16656-v1.patch, HBASE-16656-v2.patch, > HBASE-16656-v3.patch, HBASE-16656-v4.patch > > > Default backup set name is "backup". If we do backup for a backup set > "SomeSetName", by default, backup id will be generated in a form: > *SomeSetName_timestamp*. > The goal is to separate backup images between different sets. > The history command will be updated and the new command - merge will use this > backup names (prefixes) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-16566) Add nonce support to TableBackupProcedure
[ https://issues.apache.org/jira/browse/HBASE-16566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16566: -- Fix Version/s: (was: HBASE-7912) 2.0.0 > Add nonce support to TableBackupProcedure > - > > Key: HBASE-16566 > URL: https://issues.apache.org/jira/browse/HBASE-16566 > Project: HBase > Issue Type: Sub-task >Reporter: Ted Yu >Assignee: Ted Yu > Labels: backup > Fix For: 2.0.0 > > Attachments: 16566.v2.txt > > > We should pass in nonce to avoid duplicate table backup RPC (the same RPC > sent to server multiple times). > The duplicate table backup RPC may happen due to master failover. > If there is no nonce, same procedure may be executed more than once. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-16656) BackupID must include backup set name
[ https://issues.apache.org/jira/browse/HBASE-16656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16656: -- Fix Version/s: (was: HBASE-7912) 2.0.0 > BackupID must include backup set name > - > > Key: HBASE-16656 > URL: https://issues.apache.org/jira/browse/HBASE-16656 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-16656-v1.patch, HBASE-16656-v2.patch, > HBASE-16656-v3.patch, HBASE-16656-v4.patch > > > Default backup set name is "backup". If we do backup for a backup set > "SomeSetName", by default, backup id will be generated in a form: > *SomeSetName_timestamp*. > The goal is to separate backup images between different sets. > The history command will be updated and the new command - merge will use this > backup names (prefixes) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (HBASE-14141) HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits from backup tables
[ https://issues.apache.org/jira/browse/HBASE-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948051#comment-15948051 ] Vladimir Rodionov edited comment on HBASE-14141 at 3/30/17 12:04 AM: - [~enis], [~elserj] can you take a look? was (Author: vrodionov): [~te...@apache.org] can you take a look? > HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits > from backup tables > > > Key: HBASE-14141 > URL: https://issues.apache.org/jira/browse/HBASE-14141 > Project: HBase > Issue Type: New Feature >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Blocker > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-14141.HBASE-14123.v1.patch, HBASE-14141.v1.patch, > HBASE-14141.v2.patch, HBASE-14141.v4.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-16365) [C++] End to end Table::Put()
[ https://issues.apache.org/jira/browse/HBASE-16365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar resolved HBASE-16365. --- Resolution: Fixed Fix Version/s: HBASE-14850 Pushed to branch. > [C++] End to end Table::Put() > - > > Key: HBASE-16365 > URL: https://issues.apache.org/jira/browse/HBASE-16365 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Enis Soztutar > Fix For: HBASE-14850 > > Attachments: hbase-16365_v0.patch, hbase-16365-v1.patch, > hbase-16365_v2.patch > > > Make Puts end to end (table -> async table -> rpc). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-16365) [C++] End to end Table::Put()
[ https://issues.apache.org/jira/browse/HBASE-16365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-16365: -- Summary: [C++] End to end Table::Put() (was: End to end Table::Put()) > [C++] End to end Table::Put() > - > > Key: HBASE-16365 > URL: https://issues.apache.org/jira/browse/HBASE-16365 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Enis Soztutar > Attachments: hbase-16365_v0.patch, hbase-16365-v1.patch > > > Make Puts end to end (table -> async table -> rpc). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-16365) [C++] End to end Table::Put()
[ https://issues.apache.org/jira/browse/HBASE-16365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-16365: -- Attachment: hbase-16365_v2.patch v2. > [C++] End to end Table::Put() > - > > Key: HBASE-16365 > URL: https://issues.apache.org/jira/browse/HBASE-16365 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Enis Soztutar > Fix For: HBASE-14850 > > Attachments: hbase-16365_v0.patch, hbase-16365-v1.patch, > hbase-16365_v2.patch > > > Make Puts end to end (table -> async table -> rpc). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-17829) [C++] Update for simple_client
[ https://issues.apache.org/jira/browse/HBASE-17829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar resolved HBASE-17829. --- Resolution: Not A Problem We don't need this anymore. See the new code in simple-client.cc. > [C++] Update for simple_client > -- > > Key: HBASE-17829 > URL: https://issues.apache.org/jira/browse/HBASE-17829 > Project: HBase > Issue Type: Sub-task >Reporter: Sudeep Sunthankar >Assignee: Sudeep Sunthankar > Attachments: HBASE-17829.HBASE-14850.v1.patch > > > simple_client binary is failing. This patch has a fix for this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-16365) End to end Table::Put()
[ https://issues.apache.org/jira/browse/HBASE-16365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-16365: -- Summary: End to end Table::Put() (was: Hook up Put work flow) > End to end Table::Put() > --- > > Key: HBASE-16365 > URL: https://issues.apache.org/jira/browse/HBASE-16365 > Project: HBase > Issue Type: Sub-task >Reporter: Elliott Clark >Assignee: Enis Soztutar > Attachments: hbase-16365_v0.patch, hbase-16365-v1.patch > > > Make Puts end to end (table -> async table -> rpc). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17844) Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical related changes)
[ https://issues.apache.org/jira/browse/HBASE-17844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948101#comment-15948101 ] stack commented on HBASE-17844: --- .003 is rebase. TestLockManager passes locally. > Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical > related changes) > --- > > Key: HBASE-17844 > URL: https://issues.apache.org/jira/browse/HBASE-17844 > Project: HBase > Issue Type: Bug > Components: Region Assignment >Affects Versions: 2.0.0 >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-17844.master.001.patch, > HBASE-17844.master.002.patch, HBASE-17844.master.003.patch > > > Here is a patch that breaks out non-pertinent changes that made it into > HBASE-14614 in an attempt at shrinking its overall size. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17844) Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical related changes)
[ https://issues.apache.org/jira/browse/HBASE-17844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17844: -- Attachment: HBASE-17844.master.003.patch > Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical > related changes) > --- > > Key: HBASE-17844 > URL: https://issues.apache.org/jira/browse/HBASE-17844 > Project: HBase > Issue Type: Bug > Components: Region Assignment >Affects Versions: 2.0.0 >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-17844.master.001.patch, > HBASE-17844.master.002.patch, HBASE-17844.master.003.patch > > > Here is a patch that breaks out non-pertinent changes that made it into > HBASE-14614 in an attempt at shrinking its overall size. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (HBASE-15894) [C++] Put and Mutation objects
[ https://issues.apache.org/jira/browse/HBASE-15894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar resolved HBASE-15894. --- Resolution: Fixed Fix Version/s: HBASE-14850 Pushed to branch. > [C++] Put and Mutation objects > -- > > Key: HBASE-15894 > URL: https://issues.apache.org/jira/browse/HBASE-15894 > Project: HBase > Issue Type: Sub-task >Reporter: Sudeep Sunthankar >Assignee: Enis Soztutar > Fix For: HBASE-14850 > > Attachments: HBASE-15894.HBASE-14850.v1.patch, hbase-15894-v1.patch, > hbase-15894_v2.patch > > > Patch for creating Put objects. Put object so created can be passed to the > Table implementation for inserting data. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17844) Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical related changes)
[ https://issues.apache.org/jira/browse/HBASE-17844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948094#comment-15948094 ] stack commented on HBASE-17844: --- May I have a +1 here? This is a smallish patch of non-important changes -- log format, comments, etc. -- that makes the related patch smaller. > Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical > related changes) > --- > > Key: HBASE-17844 > URL: https://issues.apache.org/jira/browse/HBASE-17844 > Project: HBase > Issue Type: Bug > Components: Region Assignment >Affects Versions: 2.0.0 >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-17844.master.001.patch, > HBASE-17844.master.002.patch > > > Here is a patch that breaks out non-pertinent changes that made it into > HBASE-14614 in an attempt at shrinking its overall size. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Work started] (HBASE-15894) [C++] Put and Mutation objects
[ https://issues.apache.org/jira/browse/HBASE-15894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-15894 started by Enis Soztutar. - > [C++] Put and Mutation objects > -- > > Key: HBASE-15894 > URL: https://issues.apache.org/jira/browse/HBASE-15894 > Project: HBase > Issue Type: Sub-task >Reporter: Sudeep Sunthankar >Assignee: Enis Soztutar > Attachments: HBASE-15894.HBASE-14850.v1.patch, hbase-15894-v1.patch, > hbase-15894_v2.patch > > > Patch for creating Put objects. Put object so created can be passed to the > Table implementation for inserting data. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-15894) [C++] Put and Mutation objects
[ https://issues.apache.org/jira/browse/HBASE-15894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15894: -- Attachment: hbase-15894_v2.patch v2 patch. Now Mutation extends Row. > [C++] Put and Mutation objects > -- > > Key: HBASE-15894 > URL: https://issues.apache.org/jira/browse/HBASE-15894 > Project: HBase > Issue Type: Sub-task >Reporter: Sudeep Sunthankar >Assignee: Enis Soztutar > Attachments: HBASE-15894.HBASE-14850.v1.patch, hbase-15894-v1.patch, > hbase-15894_v2.patch > > > Patch for creating Put objects. Put object so created can be passed to the > Table implementation for inserting data. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-15894) [C++] Put and Mutation objects
[ https://issues.apache.org/jira/browse/HBASE-15894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15894: -- Summary: [C++] Put and Mutation objects (was: Put Object) > [C++] Put and Mutation objects > -- > > Key: HBASE-15894 > URL: https://issues.apache.org/jira/browse/HBASE-15894 > Project: HBase > Issue Type: Sub-task >Reporter: Sudeep Sunthankar >Assignee: Enis Soztutar > Attachments: HBASE-15894.HBASE-14850.v1.patch, hbase-15894-v1.patch > > > Patch for creating Put objects. Put object so created can be passed to the > Table implementation for inserting data. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17847) update documentation to include positions on recent Hadoop releases
[ https://issues.apache.org/jira/browse/HBASE-17847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948077#comment-15948077 ] Enis Soztutar commented on HBASE-17847: --- Belated +1. > update documentation to include positions on recent Hadoop releases > --- > > Key: HBASE-17847 > URL: https://issues.apache.org/jira/browse/HBASE-17847 > Project: HBase > Issue Type: Task > Components: community, documentation >Affects Versions: 2.0.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-17847.0.patch, HBASE-17847.1.patch > > > [per dev@hbase discussion on how to handle the most recent round of Hadoop > releases|https://lists.apache.org/thread.html/bb5591e3260f4e70d40c1f9cb30aa98d018fc145ab3aef8b3f6a4f5d@%3Cdev.hbase.apache.org%3E], > get our docs updated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17847) update documentation to include positions on recent Hadoop releases
[
https://issues.apache.org/jira/browse/HBASE-17847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948068#comment-15948068
]
Hadoop QA commented on HBASE-17847:
---
| (x) *{color:red}-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:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
30s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 16s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
30s {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} hadoopcheck {color} | {color:green}
30m 30s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 47s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 150m 17s
{color} | {color:green} root in the patch passed. {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} 196m 53s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12861087/HBASE-17847.1.patch |
| JIRA Issue | HBASE-17847 |
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux a58e782ecff4 3.13.0-105-generic #152-Ubuntu SMP Fri Dec 2
15:37:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / f159557 |
| Default Java | 1.8.0_121 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6257/testReport/ |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6257/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> update documentation to include positions on recent Hadoop releases
> ---
>
> Key: HBASE-17847
> URL: https://issues.apache.org/jira/browse/HBASE-17847
> Project: HBase
> Issue Type: Task
> Components: community, documentation
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-17847.0.patch, HBASE-17847.1.patch
>
>
> [per dev@hbase discussion on how to handle the most recent round of Hadoop
> releases|https://lists.apache.org/thread.html/bb5591e3260f4e70d40c1f9cb30aa98d018fc145ab3aef8b3f6a4f5d@%3Cdev.hbase.apache.org%3E],
> get our docs updated.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (HBASE-17771) [C++] Classes required for implementation of BatchCallerBuilder
[ https://issues.apache.org/jira/browse/HBASE-17771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-17771: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to the branch. Thanks Sudeep for the patch. > [C++] Classes required for implementation of BatchCallerBuilder > --- > > Key: HBASE-17771 > URL: https://issues.apache.org/jira/browse/HBASE-17771 > Project: HBase > Issue Type: Sub-task >Reporter: Sudeep Sunthankar >Assignee: Sudeep Sunthankar > Fix For: HBASE-14850 > > Attachments: HBASE-17771.HBASE-14850.v1.patch, > HBASE-17771.HBASE-14850.v2.patch, HBASE-17771.HBASE-14850.v3.patch, > HBASE-17771.HBASE-14850.v4.patch, HBASE-17771.HBASE-14850.v5.patch, > HBASE-17771.HBASE-14850.v6.patch > > > Separating depedencies of BatchCallerBuilder. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17849) PE tool randomness is not totally random
[ https://issues.apache.org/jira/browse/HBASE-17849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948063#comment-15948063 ] Enis Soztutar commented on HBASE-17849: --- I have noticed something like this as well where the regions generated from pre-split are not growing at the equal rate. Especially the last region(s) are relatively small. > PE tool randomness is not totally random > > > Key: HBASE-17849 > URL: https://issues.apache.org/jira/browse/HBASE-17849 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > > Recently we were using the PE tool for doing some bucket cache related > performance tests. One thing that we noted was that the way the random read > works is not totally random. > Suppose we load 200G of data using --size param and then we use --rows=50 > to do the randomRead. The assumption was among the 200G of data it could > generate randomly 50 row keys to do the reads. > But it so happens that the PE tool generates random rows only on those set of > row keys which falls under the first 50 rows. > This was quite evident when we tried to use HBASE-15314 in our testing. > Suppose we split the bucket cache of size 200G into 2 files each 100G the > randomReads with --rows=50 always lands in the first file and not in the > 2nd file. Better to make PE purely random. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-14141) HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits from backup tables
[ https://issues.apache.org/jira/browse/HBASE-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948051#comment-15948051 ] Vladimir Rodionov commented on HBASE-14141: --- [~te...@apache.org] can you take a look? > HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits > from backup tables > > > Key: HBASE-14141 > URL: https://issues.apache.org/jira/browse/HBASE-14141 > Project: HBase > Issue Type: New Feature >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Blocker > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-14141.HBASE-14123.v1.patch, HBASE-14141.v1.patch, > HBASE-14141.v2.patch, HBASE-14141.v4.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17771) [C++] Classes required for implementation of BatchCallerBuilder
[
https://issues.apache.org/jira/browse/HBASE-17771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948054#comment-15948054
]
Enis Soztutar commented on HBASE-17771:
---
Unfortunately, there is a bug introduced in {{Row::CheckRow}} causing the
get-test to fail. You are casting the size of the row to an {{int16_t}},
causing the integer overload when row.size is greater than
{{std::numeric_limits::max()}}. Anyway, good that we have the get-test
which caught it.
{code}
void CheckRow(const std::string ) {
const int16_t kMaxRowLength = std::numeric_limits::max();
int64_t row_length = row.size();
{code}
I've fixed the code and will push this to the branch.
> [C++] Classes required for implementation of BatchCallerBuilder
> ---
>
> Key: HBASE-17771
> URL: https://issues.apache.org/jira/browse/HBASE-17771
> Project: HBase
> Issue Type: Sub-task
>Reporter: Sudeep Sunthankar
>Assignee: Sudeep Sunthankar
> Fix For: HBASE-14850
>
> Attachments: HBASE-17771.HBASE-14850.v1.patch,
> HBASE-17771.HBASE-14850.v2.patch, HBASE-17771.HBASE-14850.v3.patch,
> HBASE-17771.HBASE-14850.v4.patch, HBASE-17771.HBASE-14850.v5.patch,
> HBASE-17771.HBASE-14850.v6.patch
>
>
> Separating depedencies of BatchCallerBuilder.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17844) Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical related changes)
[
https://issues.apache.org/jira/browse/HBASE-17844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947986#comment-15947986
]
Hadoop QA commented on HBASE-17844:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 9 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 22s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
47s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 31s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
56s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
36s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 15s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 9s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
30s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 23s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 23s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
31s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
54s {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} hadoopcheck {color} | {color:green}
25m 2s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
20s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 25s
{color} | {color:red} hbase-server generated 1 new + 0 unchanged - 0 fixed = 1
total (was 0) {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 53s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 42s
{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 12s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 39m 11s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 54s
{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
45s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 99m 23s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.master.locking.TestLockManager |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12861091/HBASE-17844.master.002.patch
|
| JIRA Issue | HBASE-17844 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 8aaf9bb358a3 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
[jira] [Updated] (HBASE-17852) Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental backup)
[ https://issues.apache.org/jira/browse/HBASE-17852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17852: -- Summary: Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental backup) (was: Add Fault tolerance to HBASE-14141 (Support bulk loaded files in incremental backup)) > Add Fault tolerance to HBASE-14417 (Support bulk loaded files in incremental > backup) > > > Key: HBASE-17852 > URL: https://issues.apache.org/jira/browse/HBASE-17852 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-14141) HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits from backup tables
[
https://issues.apache.org/jira/browse/HBASE-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947945#comment-15947945
]
Hadoop QA commented on HBASE-14141:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
32s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 48s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
52s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 5s
{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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
48s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {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} hadoopcheck {color} | {color:green}
29m 14s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
59s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 27s
{color} | {color:red} hbase-server generated 5 new + 0 unchanged - 0 fixed = 5
total (was 0) {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 110m 24s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 153m 31s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12861082/HBASE-14141.v4.patch |
| JIRA Issue | HBASE-14141 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux ae578ac17f4a 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / f159557 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| javadoc |
https://builds.apache.org/job/PreCommit-HBASE-Build/6256/artifact/patchprocess/diff-javadoc-javadoc-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6256/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6256/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits
> from backup tables
>
[jira] [Created] (HBASE-17852) Add Fault tolerance to HBASE-14141 (Support bulk loaded files in incremental backup)
Vladimir Rodionov created HBASE-17852: - Summary: Add Fault tolerance to HBASE-14141 (Support bulk loaded files in incremental backup) Key: HBASE-17852 URL: https://issues.apache.org/jira/browse/HBASE-17852 Project: HBase Issue Type: Sub-task Reporter: Vladimir Rodionov Assignee: Vladimir Rodionov -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-16314) Retry on table snapshot failure
[
https://issues.apache.org/jira/browse/HBASE-16314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947893#comment-15947893
]
Hadoop QA commented on HBASE-16314:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 7s {color}
| {color:red} HBASE-16314 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.3.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12840710/HBASE-16314-v4.patch |
| JIRA Issue | HBASE-16314 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6259/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Retry on table snapshot failure
> ---
>
> Key: HBASE-16314
> URL: https://issues.apache.org/jira/browse/HBASE-16314
> Project: HBase
> Issue Type: Sub-task
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Fix For: HBASE-7912
>
> Attachments: HBASE-16314-v1.patch, HBASE-16314-v2.patch,
> HBASE-16314-v3.patch, HBASE-16314-v4.patch
>
>
> Table snapshot (during full backup) can fail with NotServingRegionException
> (splits, AM region moves). We need to add retry logic here.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17851) [TEST]: WAL to HFile conversion phase MUST detect and handle missing WAL files
Vladimir Rodionov created HBASE-17851: - Summary: [TEST]: WAL to HFile conversion phase MUST detect and handle missing WAL files Key: HBASE-17851 URL: https://issues.apache.org/jira/browse/HBASE-17851 Project: HBase Issue Type: Sub-task Reporter: Vladimir Rodionov Assignee: Vladimir Rodionov The code is implemented - we need UT to verify correctness of a failure handling algo. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-15227) HBase Backup Phase 3: Fault tolerance (client/server) support
[ https://issues.apache.org/jira/browse/HBASE-15227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-15227: -- Fix Version/s: (was: HBASE-7912) 2.0.0 > HBase Backup Phase 3: Fault tolerance (client/server) support > - > > Key: HBASE-15227 > URL: https://issues.apache.org/jira/browse/HBASE-15227 > Project: HBase > Issue Type: Task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Blocker > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-15227-v3.patch, HBASE-15277-v1.patch > > > System must be tolerant to faults: > # Backup operations MUST be atomic (no partial completion state in system > table) > # Process must detect any type of failures which can result in a data loss > (partial backup) in a backup destination > # Proper system table state restore and cleanup must be done in case of a > failure > # Additional utility to repair backup system table and corresponding file > system cleanup must be implemented -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-16392) Backup delete fault tolerance
[ https://issues.apache.org/jira/browse/HBASE-16392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16392: -- Issue Type: Sub-task (was: Task) Parent: HBASE-15227 > Backup delete fault tolerance > - > > Key: HBASE-16392 > URL: https://issues.apache.org/jira/browse/HBASE-16392 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov > > Backup delete modified file system and backup system table. We have to make > sure that operation is atomic, durable and isolated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-16181) Allow snapshot of hbase:backup table
[ https://issues.apache.org/jira/browse/HBASE-16181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16181: -- Issue Type: Sub-task (was: Task) Parent: HBASE-15227 > Allow snapshot of hbase:backup table > > > Key: HBASE-16181 > URL: https://issues.apache.org/jira/browse/HBASE-16181 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Labels: backup > Fix For: HBASE-7912 > > Attachments: HBASE-16181-v1.patch, HBASE-16181-v2.patch > > > Snapshot of HBase system tables is not supported, we need either move > hbase:backup into different name space or fix snapshots. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-16314) Retry on table snapshot failure
[ https://issues.apache.org/jira/browse/HBASE-16314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-16314: -- Issue Type: Sub-task (was: New Feature) Parent: HBASE-15227 > Retry on table snapshot failure > --- > > Key: HBASE-16314 > URL: https://issues.apache.org/jira/browse/HBASE-16314 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: HBASE-7912 > > Attachments: HBASE-16314-v1.patch, HBASE-16314-v2.patch, > HBASE-16314-v3.patch, HBASE-16314-v4.patch > > > Table snapshot (during full backup) can fail with NotServingRegionException > (splits, AM region moves). We need to add retry logic here. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17850) Backup system restore /repair utility
[ https://issues.apache.org/jira/browse/HBASE-17850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17850: -- Issue Type: Sub-task (was: New Feature) Parent: HBASE-15227 > Backup system restore /repair utility > - > > Key: HBASE-17850 > URL: https://issues.apache.org/jira/browse/HBASE-17850 > Project: HBase > Issue Type: Sub-task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Labels: backup > Fix For: 2.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17850) Backup system restore /repair utility
Vladimir Rodionov created HBASE-17850: - Summary: Backup system restore /repair utility Key: HBASE-17850 URL: https://issues.apache.org/jira/browse/HBASE-17850 Project: HBase Issue Type: New Feature Reporter: Vladimir Rodionov Assignee: Vladimir Rodionov Fix For: 2.0.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-15227) HBase Backup Phase 3: Fault tolerance (client/server) support
[ https://issues.apache.org/jira/browse/HBASE-15227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-15227: -- Description: System must be tolerant to faults: # Backup operations MUST be atomic (no partial completion state in system table) # Process must detect any type of failures which can result in a data loss (partial backup) in a backup destination # Proper system table state restore and cleanup must be done in case of a failure # Additional utility to repair backup system table and corresponding file system cleanup must be implemented was:System must be tolerant to faults. Backup operations MUST be atomic (no partial completion state in system table) > HBase Backup Phase 3: Fault tolerance (client/server) support > - > > Key: HBASE-15227 > URL: https://issues.apache.org/jira/browse/HBASE-15227 > Project: HBase > Issue Type: Task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Blocker > Labels: backup > Fix For: HBASE-7912 > > Attachments: HBASE-15227-v3.patch, HBASE-15277-v1.patch > > > System must be tolerant to faults: > # Backup operations MUST be atomic (no partial completion state in system > table) > # Process must detect any type of failures which can result in a data loss > (partial backup) in a backup destination > # Proper system table state restore and cleanup must be done in case of a > failure > # Additional utility to repair backup system table and corresponding file > system cleanup must be implemented -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (HBASE-16181) Allow snapshot of hbase:backup table
[ https://issues.apache.org/jira/browse/HBASE-16181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov reopened HBASE-16181: --- > Allow snapshot of hbase:backup table > > > Key: HBASE-16181 > URL: https://issues.apache.org/jira/browse/HBASE-16181 > Project: HBase > Issue Type: Task >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Labels: backup > Fix For: HBASE-7912 > > Attachments: HBASE-16181-v1.patch, HBASE-16181-v2.patch > > > Snapshot of HBase system tables is not supported, we need either move > hbase:backup into different name space or fix snapshots. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17660) HFileSplitter is not being applied during full table restore
[ https://issues.apache.org/jira/browse/HBASE-17660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17660: -- Labels: backup (was: ) > HFileSplitter is not being applied during full table restore > > > Key: HBASE-17660 > URL: https://issues.apache.org/jira/browse/HBASE-17660 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-17660.v1.patch > > > HFileSplitter M/R job splits snapshot files into a given region boundaries > before moving them using bulk load tool. > The current code for restore full table backup does not utilize this job. > Should be fixed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17660) HFileSplitter is not being applied during full table restore
[ https://issues.apache.org/jira/browse/HBASE-17660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17660: -- Fix Version/s: (was: HBASE-7912) 2.0.0 > HFileSplitter is not being applied during full table restore > > > Key: HBASE-17660 > URL: https://issues.apache.org/jira/browse/HBASE-17660 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0 > > Attachments: HBASE-17660.v1.patch > > > HFileSplitter M/R job splits snapshot files into a given region boundaries > before moving them using bulk load tool. > The current code for restore full table backup does not utilize this job. > Should be fixed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17660) HFileSplitter is not being applied during full table restore
[ https://issues.apache.org/jira/browse/HBASE-17660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-17660: -- Resolution: Fixed Status: Resolved (was: Patch Available) The patch was part of mega-patch v61. > HFileSplitter is not being applied during full table restore > > > Key: HBASE-17660 > URL: https://issues.apache.org/jira/browse/HBASE-17660 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0 > > Attachments: HBASE-17660.v1.patch > > > HFileSplitter M/R job splits snapshot files into a given region boundaries > before moving them using bulk load tool. > The current code for restore full table backup does not utilize this job. > Should be fixed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17844) Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical related changes)
[ https://issues.apache.org/jira/browse/HBASE-17844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947829#comment-15947829 ] stack commented on HBASE-17844: --- .002 fixes TestHeapSize (forgot to fix javadoc... can do it on commit). > Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical > related changes) > --- > > Key: HBASE-17844 > URL: https://issues.apache.org/jira/browse/HBASE-17844 > Project: HBase > Issue Type: Bug > Components: Region Assignment >Affects Versions: 2.0.0 >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-17844.master.001.patch, > HBASE-17844.master.002.patch > > > Here is a patch that breaks out non-pertinent changes that made it into > HBASE-14614 in an attempt at shrinking its overall size. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17844) Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical related changes)
[ https://issues.apache.org/jira/browse/HBASE-17844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17844: -- Attachment: HBASE-17844.master.002.patch > Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical > related changes) > --- > > Key: HBASE-17844 > URL: https://issues.apache.org/jira/browse/HBASE-17844 > Project: HBase > Issue Type: Bug > Components: Region Assignment >Affects Versions: 2.0.0 >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-17844.master.001.patch, > HBASE-17844.master.002.patch > > > Here is a patch that breaks out non-pertinent changes that made it into > HBASE-14614 in an attempt at shrinking its overall size. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17847) update documentation to include positions on recent Hadoop releases
[ https://issues.apache.org/jira/browse/HBASE-17847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-17847: Status: In Progress (was: Patch Available) > update documentation to include positions on recent Hadoop releases > --- > > Key: HBASE-17847 > URL: https://issues.apache.org/jira/browse/HBASE-17847 > Project: HBase > Issue Type: Task > Components: community, documentation >Affects Versions: 2.0.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-17847.0.patch, HBASE-17847.1.patch > > > [per dev@hbase discussion on how to handle the most recent round of Hadoop > releases|https://lists.apache.org/thread.html/bb5591e3260f4e70d40c1f9cb30aa98d018fc145ab3aef8b3f6a4f5d@%3Cdev.hbase.apache.org%3E], > get our docs updated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17847) update documentation to include positions on recent Hadoop releases
[ https://issues.apache.org/jira/browse/HBASE-17847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947827#comment-15947827 ] Sean Busbey commented on HBASE-17847: - pushed to master. I'll wait for a push to the live website before I close this out. > update documentation to include positions on recent Hadoop releases > --- > > Key: HBASE-17847 > URL: https://issues.apache.org/jira/browse/HBASE-17847 > Project: HBase > Issue Type: Task > Components: community, documentation >Affects Versions: 2.0.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-17847.0.patch, HBASE-17847.1.patch > > > [per dev@hbase discussion on how to handle the most recent round of Hadoop > releases|https://lists.apache.org/thread.html/bb5591e3260f4e70d40c1f9cb30aa98d018fc145ab3aef8b3f6a4f5d@%3Cdev.hbase.apache.org%3E], > get our docs updated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17845) Documentation refers to non-existent C/C++ client library
[ https://issues.apache.org/jira/browse/HBASE-17845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947821#comment-15947821 ] Enis Soztutar commented on HBASE-17845: --- Thanks for reporting this. Moving it inside the HBASE-14850. We can update the documentation once the code is in better shape. It is getting there. > Documentation refers to non-existent C/C++ client library > - > > Key: HBASE-17845 > URL: https://issues.apache.org/jira/browse/HBASE-17845 > Project: HBase > Issue Type: Sub-task > Components: documentation >Affects Versions: 2.0.0 >Reporter: Jan Hentschel >Priority: Minor > > The documentation for the [C/C++ client|http://hbase.apache.org/book.html#c] > in the book refers to a project which does not exist anymore. We should > either remove this section or refer to the *hbase-native-client* module. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17845) Documentation refers to non-existent C/C++ client library
[ https://issues.apache.org/jira/browse/HBASE-17845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-17845: -- Issue Type: Sub-task (was: Bug) Parent: HBASE-14850 > Documentation refers to non-existent C/C++ client library > - > > Key: HBASE-17845 > URL: https://issues.apache.org/jira/browse/HBASE-17845 > Project: HBase > Issue Type: Sub-task > Components: documentation >Affects Versions: 2.0.0 >Reporter: Jan Hentschel >Priority: Minor > > The documentation for the [C/C++ client|http://hbase.apache.org/book.html#c] > in the book refers to a project which does not exist anymore. We should > either remove this section or refer to the *hbase-native-client* module. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17847) update documentation to include positions on recent Hadoop releases
[ https://issues.apache.org/jira/browse/HBASE-17847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947818#comment-15947818 ] stack commented on HBASE-17847: --- Excellent. +1 > update documentation to include positions on recent Hadoop releases > --- > > Key: HBASE-17847 > URL: https://issues.apache.org/jira/browse/HBASE-17847 > Project: HBase > Issue Type: Task > Components: community, documentation >Affects Versions: 2.0.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-17847.0.patch, HBASE-17847.1.patch > > > [per dev@hbase discussion on how to handle the most recent round of Hadoop > releases|https://lists.apache.org/thread.html/bb5591e3260f4e70d40c1f9cb30aa98d018fc145ab3aef8b3f6a4f5d@%3Cdev.hbase.apache.org%3E], > get our docs updated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17847) update documentation to include positions on recent Hadoop releases
[ https://issues.apache.org/jira/browse/HBASE-17847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-17847: Attachment: HBASE-17847.1.patch -01 - add links to the announcements for Hadoop 2.7.0 and 2.8.0, since those say the releases are non-production and should stick around. > update documentation to include positions on recent Hadoop releases > --- > > Key: HBASE-17847 > URL: https://issues.apache.org/jira/browse/HBASE-17847 > Project: HBase > Issue Type: Task > Components: community, documentation >Affects Versions: 2.0.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-17847.0.patch, HBASE-17847.1.patch > > > [per dev@hbase discussion on how to handle the most recent round of Hadoop > releases|https://lists.apache.org/thread.html/bb5591e3260f4e70d40c1f9cb30aa98d018fc145ab3aef8b3f6a4f5d@%3Cdev.hbase.apache.org%3E], > get our docs updated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-14141) HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits from backup tables
[ https://issues.apache.org/jira/browse/HBASE-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947744#comment-15947744 ] Vladimir Rodionov commented on HBASE-14141: --- Review Board: https://reviews.apache.org/r/58035/ > HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits > from backup tables > > > Key: HBASE-14141 > URL: https://issues.apache.org/jira/browse/HBASE-14141 > Project: HBase > Issue Type: New Feature >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Blocker > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-14141.HBASE-14123.v1.patch, HBASE-14141.v1.patch, > HBASE-14141.v2.patch, HBASE-14141.v4.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-14141) HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits from backup tables
[ https://issues.apache.org/jira/browse/HBASE-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-14141: -- Attachment: HBASE-14141.v4.patch v4. Handling of missing files is now in WALPlayer > HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits > from backup tables > > > Key: HBASE-14141 > URL: https://issues.apache.org/jira/browse/HBASE-14141 > Project: HBase > Issue Type: New Feature >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Blocker > Labels: backup > Fix For: 2.0.0 > > Attachments: HBASE-14141.HBASE-14123.v1.patch, HBASE-14141.v1.patch, > HBASE-14141.v2.patch, HBASE-14141.v4.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17847) update documentation to include positions on recent Hadoop releases
[ https://issues.apache.org/jira/browse/HBASE-17847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947709#comment-15947709 ] Andrew Wang commented on HBASE-17847: - Yea, looks fine to me. There are some known issues with the 3.0.0 alpha1 and alpha2, e.g. not working with secure or HA clusters. Feel free to upgrade to X if that's more appropriate. Hoping that alpha3 / beta1 are a lot closer to ready. > update documentation to include positions on recent Hadoop releases > --- > > Key: HBASE-17847 > URL: https://issues.apache.org/jira/browse/HBASE-17847 > Project: HBase > Issue Type: Task > Components: community, documentation >Affects Versions: 2.0.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-17847.0.patch > > > [per dev@hbase discussion on how to handle the most recent round of Hadoop > releases|https://lists.apache.org/thread.html/bb5591e3260f4e70d40c1f9cb30aa98d018fc145ab3aef8b3f6a4f5d@%3Cdev.hbase.apache.org%3E], > get our docs updated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17844) Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical related changes)
[
https://issues.apache.org/jira/browse/HBASE-17844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947697#comment-15947697
]
Hadoop QA commented on HBASE-17844:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 17s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 9 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
0s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 32s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
39s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
54s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 20s
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s
{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} 1m 32s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 32s
{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} mvneclipse {color} | {color:green} 0m
54s {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} hadoopcheck {color} | {color:green}
28m 16s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
54s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 29s
{color} | {color:red} hbase-server generated 1 new + 0 unchanged - 0 fixed = 1
total (was 0) {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 52s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 53s
{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 24s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 23m 24s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 2s
{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
40s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 88m 47s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.io.TestHeapSize |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12860994/HBASE-17844.master.001.patch
|
| JIRA Issue | HBASE-17844 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 7b0c22f15a1c 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Comment Edited] (HBASE-14141) HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits from backup tables
[
https://issues.apache.org/jira/browse/HBASE-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947694#comment-15947694
]
Vladimir Rodionov edited comment on HBASE-14141 at 3/29/17 6:56 PM:
{quote}
See if you can add test coverage
{quote}
No need for new tests if all old pass. The only test which is good to have is
for failure scenario (when WAL is being archived during M/R job execution), but
I have no idea how to implement this. We have FT JIRA, so probably good to have
separate JIRA for failure scenarios? Integration tests may be?
was (Author: vrodionov):
{quote}
See if you can add test coverage
{quote}
No need for new tests if all old pass. The only test which is good to have is
for failure scenario (when WAL is being archived during M/R job execution), but
I have no idea how to implement this. We have FT JIRA, so probably good to have
separate JIRA for failure scenarios?
> HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits
> from backup tables
>
>
> Key: HBASE-14141
> URL: https://issues.apache.org/jira/browse/HBASE-14141
> Project: HBase
> Issue Type: New Feature
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Blocker
> Labels: backup
> Fix For: 2.0.0
>
> Attachments: HBASE-14141.HBASE-14123.v1.patch, HBASE-14141.v1.patch,
> HBASE-14141.v2.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-14141) HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits from backup tables
[
https://issues.apache.org/jira/browse/HBASE-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947694#comment-15947694
]
Vladimir Rodionov commented on HBASE-14141:
---
{quote}
See if you can add test coverage
{quote}
No need for new tests if all old pass. The only test which is good to have is
for failure scenario (when WAL is being archived during M/R job execution), but
I have no idea how to implement this. We have FT JIRA, so probably good to have
separate JIRA for failure scenarios?
> HBase Backup/Restore Phase 3: Filter WALs on backup to include only edits
> from backup tables
>
>
> Key: HBASE-14141
> URL: https://issues.apache.org/jira/browse/HBASE-14141
> Project: HBase
> Issue Type: New Feature
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Blocker
> Labels: backup
> Fix For: 2.0.0
>
> Attachments: HBASE-14141.HBASE-14123.v1.patch, HBASE-14141.v1.patch,
> HBASE-14141.v2.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (HBASE-17816) HRegion#mutateRowWithLocks should update writeRequestCount metric
[ https://issues.apache.org/jira/browse/HBASE-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Helmling reassigned HBASE-17816: - Assignee: Weizhan Zeng (was: Ashu Pachauri) [~Weizhan Zeng], I've assigned the issue to you. This will allow you to upload a patch. From the issue, select More -> Attach Files. > HRegion#mutateRowWithLocks should update writeRequestCount metric > - > > Key: HBASE-17816 > URL: https://issues.apache.org/jira/browse/HBASE-17816 > Project: HBase > Issue Type: Bug >Reporter: Ashu Pachauri >Assignee: Weizhan Zeng > Attachments: HBASE-17816.master.001.patch > > > Currently, all the calls that use HRegion#mutateRowWithLocks miss > writeRequestCount metric. The mutateRowWithLocks base method should update > the metric. > Examples are checkAndMutate calls through RSRpcServices#multi, > Region#mutateRow api , MultiRowMutationProcessor coprocessor endpoint. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17849) PE tool randomness is not totally random
ramkrishna.s.vasudevan created HBASE-17849: -- Summary: PE tool randomness is not totally random Key: HBASE-17849 URL: https://issues.apache.org/jira/browse/HBASE-17849 Project: HBase Issue Type: Bug Components: test Affects Versions: 2.0.0 Reporter: ramkrishna.s.vasudevan Fix For: 2.0.0 Recently we were using the PE tool for doing some bucket cache related performance tests. One thing that we noted was that the way the random read works is not totally random. Suppose we load 200G of data using --size param and then we use --rows=50 to do the randomRead. The assumption was among the 200G of data it could generate randomly 50 row keys to do the reads. But it so happens that the PE tool generates random rows only on those set of row keys which falls under the first 50 rows. This was quite evident when we tried to use HBASE-15314 in our testing. Suppose we split the bucket cache of size 200G into 2 files each 100G the randomReads with --rows=50 always lands in the first file and not in the 2nd file. Better to make PE purely random. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17816) HRegion#mutateRowWithLocks should update writeRequestCount metric
[ https://issues.apache.org/jira/browse/HBASE-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947592#comment-15947592 ] Ashu Pachauri commented on HBASE-17816: --- [~Weizhan Zeng] Once you are done with your loac testing, you'll need to generate a patch and submit it on this Jira. Regarding how to submit a patch, have a look at this: https://hbase.apache.org/book.html#submitting.patches I'm going to assign the jira to to you so that you'll be able to upload a patch. > HRegion#mutateRowWithLocks should update writeRequestCount metric > - > > Key: HBASE-17816 > URL: https://issues.apache.org/jira/browse/HBASE-17816 > Project: HBase > Issue Type: Bug >Reporter: Ashu Pachauri >Assignee: Ashu Pachauri > Attachments: HBASE-17816.master.001.patch > > > Currently, all the calls that use HRegion#mutateRowWithLocks miss > writeRequestCount metric. The mutateRowWithLocks base method should update > the metric. > Examples are checkAndMutate calls through RSRpcServices#multi, > Region#mutateRow api , MultiRowMutationProcessor coprocessor endpoint. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (HBASE-17844) Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical related changes)
[ https://issues.apache.org/jira/browse/HBASE-17844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17844: -- Status: Patch Available (was: Open) > Subset of HBASE-14614, Procedure v2: Core Assignment Manager (non-critical > related changes) > --- > > Key: HBASE-17844 > URL: https://issues.apache.org/jira/browse/HBASE-17844 > Project: HBase > Issue Type: Bug > Components: Region Assignment >Affects Versions: 2.0.0 >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: HBASE-17844.master.001.patch > > > Here is a patch that breaks out non-pertinent changes that made it into > HBASE-14614 in an attempt at shrinking its overall size. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17847) update documentation to include positions on recent Hadoop releases
[ https://issues.apache.org/jira/browse/HBASE-17847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947552#comment-15947552 ] stack commented on HBASE-17847: --- LGTM. Want to link to 2.8.0 is unstable src? Thanks Sean > update documentation to include positions on recent Hadoop releases > --- > > Key: HBASE-17847 > URL: https://issues.apache.org/jira/browse/HBASE-17847 > Project: HBase > Issue Type: Task > Components: community, documentation >Affects Versions: 2.0.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-17847.0.patch > > > [per dev@hbase discussion on how to handle the most recent round of Hadoop > releases|https://lists.apache.org/thread.html/bb5591e3260f4e70d40c1f9cb30aa98d018fc145ab3aef8b3f6a4f5d@%3Cdev.hbase.apache.org%3E], > get our docs updated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17287) Master becomes a zombie if filesystem object closes
[
https://issues.apache.org/jira/browse/HBASE-17287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947545#comment-15947545
]
Hudson commented on HBASE-17287:
SUCCESS: Integrated in Jenkins build HBase-1.3-JDK8 #143 (See
[https://builds.apache.org/job/HBase-1.3-JDK8/143/])
HBASE-17287 Master becomes a zombie if filesystem object closes (tedyu: rev
8c6608f5a92e5bbd3ecc45c7cc7e28a4f05251e7)
* (add)
hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestSafemodeBringsDownMaster.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java
> Master becomes a zombie if filesystem object closes
> ---
>
> Key: HBASE-17287
> URL: https://issues.apache.org/jira/browse/HBASE-17287
> Project: HBase
> Issue Type: Bug
> Components: master
>Reporter: Clay B.
>Assignee: Ted Yu
>Priority: Blocker
> Fix For: 1.4.0, 1.3.1, 1.1.9, 2.0, 1.2.6
>
> Attachments: 17287.branch-1.1.v4.txt, 17287.branch-1.v3.txt,
> 17287.branch-1.v4.txt, 17287.master.v2.txt, 17287.master.v3.txt,
> 17287.master.v4.txt, 17287.master.v5.txt, 17287.v2.txt
>
>
> We have seen an issue whereby if the HDFS is unstable and the HBase master's
> HDFS client is unable to stabilize before
> {{dfs.client.failover.max.attempts}} then the master's filesystem object
> closes. This seems to result in an HBase master which will continue to run
> (process and znode exists) but no meaningful work can be done (e.g. assigning
> meta).What we saw in our HBase master logs was:{code}2016-12-01 19:19:08,192
> ERROR org.apache.hadoop.hbase.master.handler.MetaServerShutdownHandler:
> Caught M_META_SERVER_SHUTDOWN, count=1java.io.IOException: failed log
> splitting for cluster-r5n12.bloomberg.com,60200,1480632863218, will retryat
> org.apache.hadoop.hbase.master.handler.MetaServerShutdownHandler.process(MetaServerShutdownHandler.java:84)at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:129)at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)at
> java.lang.Thread.run(Thread.java:745)Caused by: java.io.IOException:
> Filesystem closed{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17287) Master becomes a zombie if filesystem object closes
[
https://issues.apache.org/jira/browse/HBASE-17287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947539#comment-15947539
]
Hudson commented on HBASE-17287:
SUCCESS: Integrated in Jenkins build HBase-1.3-JDK7 #134 (See
[https://builds.apache.org/job/HBase-1.3-JDK7/134/])
HBASE-17287 Master becomes a zombie if filesystem object closes (tedyu: rev
8c6608f5a92e5bbd3ecc45c7cc7e28a4f05251e7)
* (add)
hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestSafemodeBringsDownMaster.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java
> Master becomes a zombie if filesystem object closes
> ---
>
> Key: HBASE-17287
> URL: https://issues.apache.org/jira/browse/HBASE-17287
> Project: HBase
> Issue Type: Bug
> Components: master
>Reporter: Clay B.
>Assignee: Ted Yu
>Priority: Blocker
> Fix For: 1.4.0, 1.3.1, 1.1.9, 2.0, 1.2.6
>
> Attachments: 17287.branch-1.1.v4.txt, 17287.branch-1.v3.txt,
> 17287.branch-1.v4.txt, 17287.master.v2.txt, 17287.master.v3.txt,
> 17287.master.v4.txt, 17287.master.v5.txt, 17287.v2.txt
>
>
> We have seen an issue whereby if the HDFS is unstable and the HBase master's
> HDFS client is unable to stabilize before
> {{dfs.client.failover.max.attempts}} then the master's filesystem object
> closes. This seems to result in an HBase master which will continue to run
> (process and znode exists) but no meaningful work can be done (e.g. assigning
> meta).What we saw in our HBase master logs was:{code}2016-12-01 19:19:08,192
> ERROR org.apache.hadoop.hbase.master.handler.MetaServerShutdownHandler:
> Caught M_META_SERVER_SHUTDOWN, count=1java.io.IOException: failed log
> splitting for cluster-r5n12.bloomberg.com,60200,1480632863218, will retryat
> org.apache.hadoop.hbase.master.handler.MetaServerShutdownHandler.process(MetaServerShutdownHandler.java:84)at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:129)at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)at
> java.lang.Thread.run(Thread.java:745)Caused by: java.io.IOException:
> Filesystem closed{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17287) Master becomes a zombie if filesystem object closes
[
https://issues.apache.org/jira/browse/HBASE-17287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947523#comment-15947523
]
Hudson commented on HBASE-17287:
SUCCESS: Integrated in Jenkins build HBase-1.2-JDK7 #119 (See
[https://builds.apache.org/job/HBase-1.2-JDK7/119/])
HBASE-17287 Master becomes a zombie if filesystem object closes (tedyu: rev
2d79b7d5a508c2175312487db3e93d838e063ec2)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java
* (add)
hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestSafemodeBringsDownMaster.java
> Master becomes a zombie if filesystem object closes
> ---
>
> Key: HBASE-17287
> URL: https://issues.apache.org/jira/browse/HBASE-17287
> Project: HBase
> Issue Type: Bug
> Components: master
>Reporter: Clay B.
>Assignee: Ted Yu
>Priority: Blocker
> Fix For: 1.4.0, 1.3.1, 1.1.9, 2.0, 1.2.6
>
> Attachments: 17287.branch-1.1.v4.txt, 17287.branch-1.v3.txt,
> 17287.branch-1.v4.txt, 17287.master.v2.txt, 17287.master.v3.txt,
> 17287.master.v4.txt, 17287.master.v5.txt, 17287.v2.txt
>
>
> We have seen an issue whereby if the HDFS is unstable and the HBase master's
> HDFS client is unable to stabilize before
> {{dfs.client.failover.max.attempts}} then the master's filesystem object
> closes. This seems to result in an HBase master which will continue to run
> (process and znode exists) but no meaningful work can be done (e.g. assigning
> meta).What we saw in our HBase master logs was:{code}2016-12-01 19:19:08,192
> ERROR org.apache.hadoop.hbase.master.handler.MetaServerShutdownHandler:
> Caught M_META_SERVER_SHUTDOWN, count=1java.io.IOException: failed log
> splitting for cluster-r5n12.bloomberg.com,60200,1480632863218, will retryat
> org.apache.hadoop.hbase.master.handler.MetaServerShutdownHandler.process(MetaServerShutdownHandler.java:84)at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:129)at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)at
> java.lang.Thread.run(Thread.java:745)Caused by: java.io.IOException:
> Filesystem closed{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17847) update documentation to include positions on recent Hadoop releases
[
https://issues.apache.org/jira/browse/HBASE-17847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947516#comment-15947516
]
Hadoop QA commented on HBASE-17847:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 17s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s
{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
15s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
26s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 13s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
26s {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} hadoopcheck {color} | {color:green}
27m 56s {color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 4s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 119m 3s {color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 161m 26s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12861050/HBASE-17847.0.patch |
| JIRA Issue | HBASE-17847 |
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux 2bdc43567441 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / f159557 |
| Default Java | 1.8.0_121 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/6254/artifact/patchprocess/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/6254/testReport/ |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/6254/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> update documentation to include positions on recent Hadoop releases
> ---
>
> Key: HBASE-17847
> URL: https://issues.apache.org/jira/browse/HBASE-17847
> Project: HBase
> Issue Type: Task
> Components: community, documentation
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-17847.0.patch
>
>
> [per dev@hbase discussion on how to handle the most recent round of Hadoop
> releases|https://lists.apache.org/thread.html/bb5591e3260f4e70d40c1f9cb30aa98d018fc145ab3aef8b3f6a4f5d@%3Cdev.hbase.apache.org%3E],
> get our docs updated.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17287) Master becomes a zombie if filesystem object closes
[
https://issues.apache.org/jira/browse/HBASE-17287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947482#comment-15947482
]
Hudson commented on HBASE-17287:
SUCCESS: Integrated in Jenkins build HBase-1.2-JDK8 #115 (See
[https://builds.apache.org/job/HBase-1.2-JDK8/115/])
HBASE-17287 Master becomes a zombie if filesystem object closes (tedyu: rev
2d79b7d5a508c2175312487db3e93d838e063ec2)
* (add)
hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestSafemodeBringsDownMaster.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java
> Master becomes a zombie if filesystem object closes
> ---
>
> Key: HBASE-17287
> URL: https://issues.apache.org/jira/browse/HBASE-17287
> Project: HBase
> Issue Type: Bug
> Components: master
>Reporter: Clay B.
>Assignee: Ted Yu
>Priority: Blocker
> Fix For: 1.4.0, 1.3.1, 1.1.9, 2.0, 1.2.6
>
> Attachments: 17287.branch-1.1.v4.txt, 17287.branch-1.v3.txt,
> 17287.branch-1.v4.txt, 17287.master.v2.txt, 17287.master.v3.txt,
> 17287.master.v4.txt, 17287.master.v5.txt, 17287.v2.txt
>
>
> We have seen an issue whereby if the HDFS is unstable and the HBase master's
> HDFS client is unable to stabilize before
> {{dfs.client.failover.max.attempts}} then the master's filesystem object
> closes. This seems to result in an HBase master which will continue to run
> (process and znode exists) but no meaningful work can be done (e.g. assigning
> meta).What we saw in our HBase master logs was:{code}2016-12-01 19:19:08,192
> ERROR org.apache.hadoop.hbase.master.handler.MetaServerShutdownHandler:
> Caught M_META_SERVER_SHUTDOWN, count=1java.io.IOException: failed log
> splitting for cluster-r5n12.bloomberg.com,60200,1480632863218, will retryat
> org.apache.hadoop.hbase.master.handler.MetaServerShutdownHandler.process(MetaServerShutdownHandler.java:84)at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:129)at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)at
> java.lang.Thread.run(Thread.java:745)Caused by: java.io.IOException:
> Filesystem closed{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17816) HRegion#mutateRowWithLocks should update writeRequestCount metric
[ https://issues.apache.org/jira/browse/HBASE-17816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947457#comment-15947457 ] Weizhan Zeng commented on HBASE-17816: -- [~ashu210890] Got it ! sorry , busy for other thing . do you know how can i upload my test code ? i an newer . > HRegion#mutateRowWithLocks should update writeRequestCount metric > - > > Key: HBASE-17816 > URL: https://issues.apache.org/jira/browse/HBASE-17816 > Project: HBase > Issue Type: Bug >Reporter: Ashu Pachauri >Assignee: Ashu Pachauri > Attachments: HBASE-17816.master.001.patch > > > Currently, all the calls that use HRegion#mutateRowWithLocks miss > writeRequestCount metric. The mutateRowWithLocks base method should update > the metric. > Examples are checkAndMutate calls through RSRpcServices#multi, > Region#mutateRow api , MultiRowMutationProcessor coprocessor endpoint. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (HBASE-17287) Master becomes a zombie if filesystem object closes
[
https://issues.apache.org/jira/browse/HBASE-17287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947434#comment-15947434
]
Hudson commented on HBASE-17287:
SUCCESS: Integrated in Jenkins build HBase-1.1-JDK8 #1939 (See
[https://builds.apache.org/job/HBase-1.1-JDK8/1939/])
HBASE-17287 Master becomes a zombie if filesystem object closes (tedyu: rev
1fdb97ce840c10f2b2e4aa4a5c636ae98bfc1c33)
* (add)
hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestSafemodeBringsDownMaster.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java
> Master becomes a zombie if filesystem object closes
> ---
>
> Key: HBASE-17287
> URL: https://issues.apache.org/jira/browse/HBASE-17287
> Project: HBase
> Issue Type: Bug
> Components: master
>Reporter: Clay B.
>Assignee: Ted Yu
>Priority: Blocker
> Fix For: 1.4.0, 1.3.1, 1.1.9, 2.0, 1.2.6
>
> Attachments: 17287.branch-1.1.v4.txt, 17287.branch-1.v3.txt,
> 17287.branch-1.v4.txt, 17287.master.v2.txt, 17287.master.v3.txt,
> 17287.master.v4.txt, 17287.master.v5.txt, 17287.v2.txt
>
>
> We have seen an issue whereby if the HDFS is unstable and the HBase master's
> HDFS client is unable to stabilize before
> {{dfs.client.failover.max.attempts}} then the master's filesystem object
> closes. This seems to result in an HBase master which will continue to run
> (process and znode exists) but no meaningful work can be done (e.g. assigning
> meta).What we saw in our HBase master logs was:{code}2016-12-01 19:19:08,192
> ERROR org.apache.hadoop.hbase.master.handler.MetaServerShutdownHandler:
> Caught M_META_SERVER_SHUTDOWN, count=1java.io.IOException: failed log
> splitting for cluster-r5n12.bloomberg.com,60200,1480632863218, will retryat
> org.apache.hadoop.hbase.master.handler.MetaServerShutdownHandler.process(MetaServerShutdownHandler.java:84)at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:129)at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)at
> java.lang.Thread.run(Thread.java:745)Caused by: java.io.IOException:
> Filesystem closed{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (HBASE-17287) Master becomes a zombie if filesystem object closes
[
https://issues.apache.org/jira/browse/HBASE-17287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947419#comment-15947419
]
Hudson commented on HBASE-17287:
FAILURE: Integrated in Jenkins build HBase-1.1-JDK7 #1855 (See
[https://builds.apache.org/job/HBase-1.1-JDK7/1855/])
HBASE-17287 Master becomes a zombie if filesystem object closes (tedyu: rev
1fdb97ce840c10f2b2e4aa4a5c636ae98bfc1c33)
* (add)
hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestSafemodeBringsDownMaster.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java
> Master becomes a zombie if filesystem object closes
> ---
>
> Key: HBASE-17287
> URL: https://issues.apache.org/jira/browse/HBASE-17287
> Project: HBase
> Issue Type: Bug
> Components: master
>Reporter: Clay B.
>Assignee: Ted Yu
>Priority: Blocker
> Fix For: 1.4.0, 1.3.1, 1.1.9, 2.0, 1.2.6
>
> Attachments: 17287.branch-1.1.v4.txt, 17287.branch-1.v3.txt,
> 17287.branch-1.v4.txt, 17287.master.v2.txt, 17287.master.v3.txt,
> 17287.master.v4.txt, 17287.master.v5.txt, 17287.v2.txt
>
>
> We have seen an issue whereby if the HDFS is unstable and the HBase master's
> HDFS client is unable to stabilize before
> {{dfs.client.failover.max.attempts}} then the master's filesystem object
> closes. This seems to result in an HBase master which will continue to run
> (process and znode exists) but no meaningful work can be done (e.g. assigning
> meta).What we saw in our HBase master logs was:{code}2016-12-01 19:19:08,192
> ERROR org.apache.hadoop.hbase.master.handler.MetaServerShutdownHandler:
> Caught M_META_SERVER_SHUTDOWN, count=1java.io.IOException: failed log
> splitting for cluster-r5n12.bloomberg.com,60200,1480632863218, will retryat
> org.apache.hadoop.hbase.master.handler.MetaServerShutdownHandler.process(MetaServerShutdownHandler.java:84)at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:129)at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)at
> java.lang.Thread.run(Thread.java:745)Caused by: java.io.IOException:
> Filesystem closed{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (HBASE-14978) Don't allow Multi to retain too many blocks
[ https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947372#comment-15947372 ] stack edited comment on HBASE-14978 at 3/29/17 3:46 PM: Makes sense [~anoop.hbase] Should be easy enough to verify. We should just not do this trick when Cell is backed by BucketCache? Open new issue? Can we get a metric in here on how effective (or frustrating) this change is? was (Author: stack): Makes sense [~anoop.hbase] Should be easy enough to verify. We should just not do this trick when Cell is backed by BucketCache? > Don't allow Multi to retain too many blocks > --- > > Key: HBASE-14978 > URL: https://issues.apache.org/jira/browse/HBASE-14978 > Project: HBase > Issue Type: Improvement > Components: io, IPC/RPC, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Blocker > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-14978-branch-1.2.patch, > HBASE-14978-branch-1.2.patch, HBASE-14978-branch-1.2.patch, > HBASE-14978-branch-1.2.patch, HBASE-14978.patch, HBASE-14978-v1.patch, > HBASE-14978-v2.patch, HBASE-14978-v3.patch, HBASE-14978-v4.patch > > > Scans and Multi's have limits on the total size of cells that can be > returned. However if those requests are not all pointing at the same blocks > then the KeyValues can keep alive a lot more data than their size. > Take the following example: > A multi with a list of 1 gets to a fat row. Each column being returned in > in a different block. Each column is small 32 bytes or so. > So the total cell size will be 32 * 1 = ~320kb. However if each block is > 128k then total retained heap size will be almost 2gigs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
