[jira] [Commented] (HBASE-15806) An endpoint-based export tool
[ https://issues.apache.org/jira/browse/HBASE-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297729#comment-15297729 ] Devaraj Das commented on HBASE-15806: - Good catch there [~mbertozzi]. If what you are saying is true, it introduces a security hole. [~yuzhih...@gmail.com], we shouldn't add more security holes in the codebase if we can. Examples of earlier issues being present in the codebase doesn't automatically justify introducing a new issue. > An endpoint-based export tool > - > > Key: HBASE-15806 > URL: https://issues.apache.org/jira/browse/HBASE-15806 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: Experiment.png, HBASE-15806.patch > > > The time for exporting table can be reduced, if we use the endpoint technique > to export the hdfs files by the region server rather than by hbase client. > In my experiments, the elapsed time of endpoint-based export can be less than > half of current export tool (enable the hdfs compression) > But the shortcomings is we need to alter table for deploying the endpoint > any comments about this? thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15867) Move HBase replication tracking from ZooKeeper to HBase
[ https://issues.apache.org/jira/browse/HBASE-15867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297716#comment-15297716 ] Heng Chen commented on HBASE-15867: --- Not sure progress of HBASE-13773 by [~sukuna...@gmail.com] > Move HBase replication tracking from ZooKeeper to HBase > --- > > Key: HBASE-15867 > URL: https://issues.apache.org/jira/browse/HBASE-15867 > Project: HBase > Issue Type: New Feature > Components: Replication >Reporter: Joseph >Assignee: Joseph > > Move the WAL file and offset tracking from ZooKeeper into an HBase table for > replication. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14140) HBase Backup/Restore Phase 3: Enhance HBaseAdmin API to include backup/restore - related API
[ https://issues.apache.org/jira/browse/HBASE-14140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-14140: -- Attachment: HBASE-14140-v12.patch fixed more UTs > HBase Backup/Restore Phase 3: Enhance HBaseAdmin API to include > backup/restore - related API > > > Key: HBASE-14140 > URL: https://issues.apache.org/jira/browse/HBASE-14140 > Project: HBase > Issue Type: New Feature >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-14140-v1.patch, HBASE-14140-v10.patch, > HBASE-14140-v11.patch, HBASE-14140-v12.patch, HBASE-14140-v4.patch, > HBASE-14140-v7.patch, HBASE-14140-v9.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-4368) Expose processlist in shell (per regionserver and perhaps by cluster)
[ https://issues.apache.org/jira/browse/HBASE-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297635#comment-15297635 ] Hudson commented on HBASE-4368: --- SUCCESS: Integrated in HBase-Trunk_matrix #944 (See [https://builds.apache.org/job/HBase-Trunk_matrix/944/]) HBASE-4368 Expose processlist in shell (per regionserver and perhaps by (stack: rev 2515b0974d84421f47a18f9e20b5fe215a95cf8f) * hbase-shell/src/main/ruby/hbase/taskmonitor.rb * hbase-shell/src/main/ruby/hbase/admin.rb * hbase-shell/src/test/ruby/hbase/taskmonitor_test.rb * hbase-shell/src/main/ruby/shell.rb * hbase-shell/src/test/ruby/test_helper.rb * hbase-shell/src/main/ruby/hbase/hbase.rb * hbase-shell/src/test/java/org/apache/hadoop/hbase/client/AbstractTestShell.java * hbase-shell/src/main/ruby/shell/commands/processlist.rb * hbase-shell/src/main/ruby/hbase.rb * hbase-shell/src/main/ruby/shell/commands.rb > Expose processlist in shell (per regionserver and perhaps by cluster) > - > > Key: HBASE-4368 > URL: https://issues.apache.org/jira/browse/HBASE-4368 > Project: HBase > Issue Type: Task > Components: shell >Reporter: stack >Assignee: Talat UYARER > Labels: beginner > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-4368.patch, HBASE-4368v2-withunittest.patch, > HBASE-4368v2.patch, HBASE-4368v3.patch, HBASE-4368v4.patch, > HBASE-4368v5-branch-1.patch > > > HBASE-4057 adds processlist and it shows in the RS UI. This issue is about > getting the processlist to show in the shell, like it does in mysql. > Labelling it noob; this is a pretty substantial issue but it shouldn't be too > hard -- it'd mostly be plumbing from RS into the shell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15837) Memstore size accounting is wrong if postBatchMutate() throws exception
[
https://issues.apache.org/jira/browse/HBASE-15837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297626#comment-15297626
]
Hadoop QA commented on HBASE-15837:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
5s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 46s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{color} | {color:green} master passed with JDK v1.7.0_79 {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
15s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
42s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 40s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
56s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 8m
34s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 103m 21s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 127m 29s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12804848/hbase-15837-v1.patch |
| JIRA Issue | HBASE-15837 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf907.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/test_framework/yetus-0.2.1/lib/precommit/personality/hbase.sh
|
| git revision | master / 2515b09 |
| Default Java | 1.7.0_79 |
| Multi-JDK versions | /home/jenkins/tools/java/jdk1.8.0:1.8.0
/usr/local/jenkins/java/jdk1.7.0_79:1.7.0_79 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/2005/testReport/ |
| modules | C: hbase-server U:
[jira] [Commented] (HBASE-15790) Force "hbase" ownership on bulkload
[
https://issues.apache.org/jira/browse/HBASE-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297603#comment-15297603
]
Hadoop QA commented on HBASE-15790:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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 12s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
56s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 4s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 48s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
47s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
24s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
36s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 50s
{color} | {color:green} master passed with JDK v1.7.0_79 {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} 0m
59s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 4s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 4s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
50s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
24s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 9m
5s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
10s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 59s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 45s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 102m 31s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
27s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 134m 18s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12805789/HBASE-15790-v3.patch |
| JIRA Issue | HBASE-15790 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf907.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HBASE-15880) RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
[
https://issues.apache.org/jira/browse/HBASE-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297571#comment-15297571
]
Hudson commented on HBASE-15880:
FAILURE: Integrated in HBase-1.2 #635 (See
[https://builds.apache.org/job/HBase-1.2/635/])
HBASE-15880 RpcClientImpl#tracedWriteRequest incorrectly closes HTrace
(antonov: rev 254579893cd123fb8d027e127019649c473e5287)
* hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClientImpl.java
> RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
> ---
>
> Key: HBASE-15880
> URL: https://issues.apache.org/jira/browse/HBASE-15880
> Project: HBase
> Issue Type: Bug
> Components: tracing
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 1.3.0
>
> Attachments: HBASE-15880-branch-1.3.v1.patch
>
>
> In this method we continue the span and then close it, which causes the
> current span (the one created by client app around HTabl#get() or similar API
> call) to be closed incorrectly.
> {code}
> TraceScope ts = Trace.continueSpan(span);
> try {
> writeRequest(call, priority, span);
> } finally {
> ts.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15880) RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
[
https://issues.apache.org/jira/browse/HBASE-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297570#comment-15297570
]
Hudson commented on HBASE-15880:
SUCCESS: Integrated in HBase-1.3-IT #677 (See
[https://builds.apache.org/job/HBase-1.3-IT/677/])
HBASE-15880 RpcClientImpl#tracedWriteRequest incorrectly closes HTrace
(antonov: rev 37e080d7018c9f5fdddb902f9898c464bbe07028)
* hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClientImpl.java
> RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
> ---
>
> Key: HBASE-15880
> URL: https://issues.apache.org/jira/browse/HBASE-15880
> Project: HBase
> Issue Type: Bug
> Components: tracing
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 1.3.0
>
> Attachments: HBASE-15880-branch-1.3.v1.patch
>
>
> In this method we continue the span and then close it, which causes the
> current span (the one created by client app around HTabl#get() or similar API
> call) to be closed incorrectly.
> {code}
> TraceScope ts = Trace.continueSpan(span);
> try {
> writeRequest(call, priority, span);
> } finally {
> ts.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-4368) Expose processlist in shell (per regionserver and perhaps by cluster)
[ https://issues.apache.org/jira/browse/HBASE-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297554#comment-15297554 ] Hudson commented on HBASE-4368: --- FAILURE: Integrated in HBase-1.4 #174 (See [https://builds.apache.org/job/HBase-1.4/174/]) HBASE-4368 Expose processlist in shell (per regionserver and perhaps by (stack: rev 627b48b799f767b1891deb8c173d0caed7862c80) * hbase-shell/src/test/java/org/apache/hadoop/hbase/client/AbstractTestShell.java * hbase-shell/src/main/ruby/shell.rb * hbase-shell/src/main/ruby/shell/commands.rb * hbase-shell/src/main/ruby/hbase/admin.rb * hbase-shell/src/test/ruby/hbase/taskmonitor_test.rb * hbase-shell/src/test/ruby/test_helper.rb * hbase-shell/src/main/ruby/hbase/taskmonitor.rb * hbase-shell/src/main/ruby/hbase/hbase.rb * hbase-shell/src/main/ruby/shell/commands/processlist.rb * hbase-shell/src/main/ruby/hbase.rb > Expose processlist in shell (per regionserver and perhaps by cluster) > - > > Key: HBASE-4368 > URL: https://issues.apache.org/jira/browse/HBASE-4368 > Project: HBase > Issue Type: Task > Components: shell >Reporter: stack >Assignee: Talat UYARER > Labels: beginner > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-4368.patch, HBASE-4368v2-withunittest.patch, > HBASE-4368v2.patch, HBASE-4368v3.patch, HBASE-4368v4.patch, > HBASE-4368v5-branch-1.patch > > > HBASE-4057 adds processlist and it shows in the RS UI. This issue is about > getting the processlist to show in the shell, like it does in mysql. > Labelling it noob; this is a pretty substantial issue but it shouldn't be too > hard -- it'd mostly be plumbing from RS into the shell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-4368) Expose processlist in shell (per regionserver and perhaps by cluster)
[ https://issues.apache.org/jira/browse/HBASE-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297523#comment-15297523 ] Talat UYARER commented on HBASE-4368: - I am not good at writing release note. Could you help me [~stack] ? > Expose processlist in shell (per regionserver and perhaps by cluster) > - > > Key: HBASE-4368 > URL: https://issues.apache.org/jira/browse/HBASE-4368 > Project: HBase > Issue Type: Task > Components: shell >Reporter: stack >Assignee: Talat UYARER > Labels: beginner > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-4368.patch, HBASE-4368v2-withunittest.patch, > HBASE-4368v2.patch, HBASE-4368v3.patch, HBASE-4368v4.patch, > HBASE-4368v5-branch-1.patch > > > HBASE-4057 adds processlist and it shows in the RS UI. This issue is about > getting the processlist to show in the shell, like it does in mysql. > Labelling it noob; this is a pretty substantial issue but it shouldn't be too > hard -- it'd mostly be plumbing from RS into the shell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15837) Memstore size accounting is wrong if postBatchMutate() throws exception
[ https://issues.apache.org/jira/browse/HBASE-15837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297503#comment-15297503 ] Josh Elser commented on HBASE-15837: bq. I was not able to find the "submit patch" button. Do you see it? Button clicked :). v1 looks good to me too. Thanks for consolidating! > Memstore size accounting is wrong if postBatchMutate() throws exception > --- > > Key: HBASE-15837 > URL: https://issues.apache.org/jira/browse/HBASE-15837 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0 > > Attachments: HBASE-15837.001.patch, hbase-15837-v1.patch, > hbase-memstore-size-accounting.patch > > > Over in PHOENIX-2883, I've been trying to figure out how to track down the > root cause of an issue we were seeing where a negative memstoreSize was > ultimately causing an RS to abort. The tl;dr version is > * Something causes memstoreSize to be negative (not sure what is doing this > yet) > * All subsequent flushes short-circuit and don't run because they think there > is no data to flush > * The region is eventually closed (commonly, for a move). > * A final flush is attempted on each store before closing (which also > short-circuit for the same reason), leaving unflushed data in each store. > * The sanity check that each store's size is zero fails and the RS aborts. > I have a little patch which I think should improve our failure case around > this, preventing the RS abort safely (forcing a flush when memstoreSize is > negative) and logging a calltrace when an update to memstoreSize make it > negative (to find culprits in the future). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15837) Memstore size accounting is wrong if postBatchMutate() throws exception
[ https://issues.apache.org/jira/browse/HBASE-15837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-15837: --- Status: Patch Available (was: In Progress) > Memstore size accounting is wrong if postBatchMutate() throws exception > --- > > Key: HBASE-15837 > URL: https://issues.apache.org/jira/browse/HBASE-15837 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0 > > Attachments: HBASE-15837.001.patch, hbase-15837-v1.patch, > hbase-memstore-size-accounting.patch > > > Over in PHOENIX-2883, I've been trying to figure out how to track down the > root cause of an issue we were seeing where a negative memstoreSize was > ultimately causing an RS to abort. The tl;dr version is > * Something causes memstoreSize to be negative (not sure what is doing this > yet) > * All subsequent flushes short-circuit and don't run because they think there > is no data to flush > * The region is eventually closed (commonly, for a move). > * A final flush is attempted on each store before closing (which also > short-circuit for the same reason), leaving unflushed data in each store. > * The sanity check that each store's size is zero fails and the RS aborts. > I have a little patch which I think should improve our failure case around > this, preventing the RS abort safely (forcing a flush when memstoreSize is > negative) and logging a calltrace when an update to memstoreSize make it > negative (to find culprits in the future). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-4368) Expose processlist in shell (per regionserver and perhaps by cluster)
[ https://issues.apache.org/jira/browse/HBASE-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297487#comment-15297487 ] Talat UYARER commented on HBASE-4368: - Got it stack. :) > Expose processlist in shell (per regionserver and perhaps by cluster) > - > > Key: HBASE-4368 > URL: https://issues.apache.org/jira/browse/HBASE-4368 > Project: HBase > Issue Type: Task > Components: shell >Reporter: stack >Assignee: Talat UYARER > Labels: beginner > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-4368.patch, HBASE-4368v2-withunittest.patch, > HBASE-4368v2.patch, HBASE-4368v3.patch, HBASE-4368v4.patch, > HBASE-4368v5-branch-1.patch > > > HBASE-4057 adds processlist and it shows in the RS UI. This issue is about > getting the processlist to show in the shell, like it does in mysql. > Labelling it noob; this is a pretty substantial issue but it shouldn't be too > hard -- it'd mostly be plumbing from RS into the shell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15806) An endpoint-based export tool
[ https://issues.apache.org/jira/browse/HBASE-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297485#comment-15297485 ] Ted Yu commented on HBASE-15806: Same pattern can be observed in ColumnAggregationEndpoint.java The above is not unique to the ExportEndpoint, right ? > An endpoint-based export tool > - > > Key: HBASE-15806 > URL: https://issues.apache.org/jira/browse/HBASE-15806 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: Experiment.png, HBASE-15806.patch > > > The time for exporting table can be reduced, if we use the endpoint technique > to export the hdfs files by the region server rather than by hbase client. > In my experiments, the elapsed time of endpoint-based export can be less than > half of current export tool (enable the hdfs compression) > But the shortcomings is we need to alter table for deploying the endpoint > any comments about this? thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15790) Force "hbase" ownership on bulkload
[ https://issues.apache.org/jira/browse/HBASE-15790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-15790: Attachment: HBASE-15790-v3.patch yeah you are right. I tested with various configuration and looks like no user aside superuser can change ownership. systest can't chown to hbase hbase can't chown to hbase a file owned by systest SecureBulkLoadEndpoint seems to always do the chmod 777. so we are good in that case even if the files are owned by someone that is not hbase. I changed the patch in v3. to check for 777 permission. and if not try to do a chown. if not able it will print a message telling the user what to do. (We have a bunch of cases of files not owned by hbase and with not enough permission that end up getting the cluster stuck, so in theory this will improve a bit the situation) > Force "hbase" ownership on bulkload > --- > > Key: HBASE-15790 > URL: https://issues.apache.org/jira/browse/HBASE-15790 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 2.0.0, 1.2.1, 1.1.4, 0.98.19 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Minor > Attachments: HBASE-15790-v0.patch, HBASE-15790-v1.patch, > HBASE-15790-v2.patch, HBASE-15790-v3.patch > > > When a user different than "hbase" bulkload files, in general we end up with > files owned by a user different than hbase. sometimes this causes problems > with hbase not be able to move files around archiving/deleting. > A simple solution is probably to change the ownership of the files to "hbase" > during bulkload. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15806) An endpoint-based export tool
[ https://issues.apache.org/jira/browse/HBASE-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297468#comment-15297468 ] Matteo Bertozzi commented on HBASE-15806: - the HRegion.getScanner() does not call the preScannerOpen() coprocessor. looks like that call is only done by RSRpcServices when we receive the scan request. so, by skipping the coprocessor it means we can pass a scan on a table where we don't have access and be able to get the dump of the data > An endpoint-based export tool > - > > Key: HBASE-15806 > URL: https://issues.apache.org/jira/browse/HBASE-15806 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: Experiment.png, HBASE-15806.patch > > > The time for exporting table can be reduced, if we use the endpoint technique > to export the hdfs files by the region server rather than by hbase client. > In my experiments, the elapsed time of endpoint-based export can be less than > half of current export tool (enable the hdfs compression) > But the shortcomings is we need to alter table for deploying the endpoint > any comments about this? thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15806) An endpoint-based export tool
[
https://issues.apache.org/jira/browse/HBASE-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297465#comment-15297465
]
Ted Yu commented on HBASE-15806:
>From RowCountEndpoint.java :
{code}
InternalScanner scanner = null;
try {
scanner = env.getRegion().getScanner(scan);
{code}
Can you be a bit more specific about the concern you have ?
> An endpoint-based export tool
> -
>
> Key: HBASE-15806
> URL: https://issues.apache.org/jira/browse/HBASE-15806
> Project: HBase
> Issue Type: New Feature
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: Experiment.png, HBASE-15806.patch
>
>
> The time for exporting table can be reduced, if we use the endpoint technique
> to export the hdfs files by the region server rather than by hbase client.
> In my experiments, the elapsed time of endpoint-based export can be less than
> half of current export tool (enable the hdfs compression)
> But the shortcomings is we need to alter table for deploying the endpoint
> any comments about this? thanks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15112) Allow coprocessors to extend 'software attributes' list
[
https://issues.apache.org/jira/browse/HBASE-15112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297452#comment-15297452
]
Matt Warhaftig commented on HBASE-15112:
Hi [~ndimiduk], What do you think about approaching this by adding a new
interface that extends the existing {{org.apache.hadoop.hbase.Coprocessor}}
interface and only adds:
{noformat}
public Map coprocessorAttributes();
{noformat}
The implemented method's returned map of specified attribute key and value
would be published to the master or rs 'Software Attributes' list.
> Allow coprocessors to extend 'software attributes' list
> ---
>
> Key: HBASE-15112
> URL: https://issues.apache.org/jira/browse/HBASE-15112
> Project: HBase
> Issue Type: Improvement
> Components: Coprocessors
>Reporter: Nick Dimiduk
>
> Over on the {{/master-status}} and {{/rs-status}} pages we have a list of
> release properties, giving details about the cluster deployment. We should
> make this an extension point, allowing coprocessors to register information
> about themselves as well. For example, Phoenix, Trafodion, Tephra, might
> want to advertise installed version and build details as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15880) RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
[
https://issues.apache.org/jira/browse/HBASE-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297444#comment-15297444
]
Nick Dimiduk commented on HBASE-15880:
--
+1 for 1.1.
> RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
> ---
>
> Key: HBASE-15880
> URL: https://issues.apache.org/jira/browse/HBASE-15880
> Project: HBase
> Issue Type: Bug
> Components: tracing
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 1.3.0
>
> Attachments: HBASE-15880-branch-1.3.v1.patch
>
>
> In this method we continue the span and then close it, which causes the
> current span (the one created by client app around HTabl#get() or similar API
> call) to be closed incorrectly.
> {code}
> TraceScope ts = Trace.continueSpan(span);
> try {
> writeRequest(call, priority, span);
> } finally {
> ts.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15867) Move HBase replication tracking from ZooKeeper to HBase
[ https://issues.apache.org/jira/browse/HBASE-15867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297434#comment-15297434 ] Gary Helmling commented on HBASE-15867: --- [~chenheng], [~sukuna...@gmail.com], the last update I see to HBASE-13773 is from October. Is anyone actively working on this? > Move HBase replication tracking from ZooKeeper to HBase > --- > > Key: HBASE-15867 > URL: https://issues.apache.org/jira/browse/HBASE-15867 > Project: HBase > Issue Type: New Feature > Components: Replication >Reporter: Joseph >Assignee: Joseph > > Move the WAL file and offset tracking from ZooKeeper into an HBase table for > replication. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15806) An endpoint-based export tool
[ https://issues.apache.org/jira/browse/HBASE-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297432#comment-15297432 ] Matteo Bertozzi commented on HBASE-15806: - sorry, I'm late for the review. but is this export bypassing all the ACLs and Visibility tags? I see a region.getScanner() so I guess we are bypassing all the logic. but I haven't looked at the patch in details yet > An endpoint-based export tool > - > > Key: HBASE-15806 > URL: https://issues.apache.org/jira/browse/HBASE-15806 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: Experiment.png, HBASE-15806.patch > > > The time for exporting table can be reduced, if we use the endpoint technique > to export the hdfs files by the region server rather than by hbase client. > In my experiments, the elapsed time of endpoint-based export can be less than > half of current export tool (enable the hdfs compression) > But the shortcomings is we need to alter table for deploying the endpoint > any comments about this? thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297425#comment-15297425
]
Hudson commented on HBASE-15876:
SUCCESS: Integrated in HBase-1.1-JDK8 #1807 (See
[https://builds.apache.org/job/HBase-1.1-JDK8/1807/])
HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) though (stack:
rev 4b28cd89abea32afd948e3acc1f16106e8cf67f7)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
Revert "HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) (stack:
rev b90d0dec18682dea06bab0b8abde1d92805f2c2c)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15878) Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even though its 'late')
[ https://issues.apache.org/jira/browse/HBASE-15878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297424#comment-15297424 ] Hudson commented on HBASE-15878: SUCCESS: Integrated in HBase-1.1-JDK8 #1807 (See [https://builds.apache.org/job/HBase-1.1-JDK8/1807/]) HBASE-15878 Deprecate doBulkLoad(Path hfofDir, final HTable table) in (stack: rev 921ecef3864901e74b8a87f83eb34d1e621ce0ba) * hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java > Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even > though its 'late') > > > Key: HBASE-15878 > URL: https://issues.apache.org/jira/browse/HBASE-15878 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack > Fix For: 1.3.0, 1.2.2, 1.1.6 > > Attachments: 15878.patch > > > The parent issue is about our removing doBulkLoad(Path hfofDir, final HTable > table) in branch-2 even though it did not go through a proper deprecation > cycle. Here we are doing a backfill of deprecations (though it too late for > doBulkLoad(Path hfofDir, final HTable table) to enjoy a proper deprecation > cycle). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297402#comment-15297402
]
Hudson commented on HBASE-15876:
FAILURE: Integrated in HBase-1.1-JDK7 #1721 (See
[https://builds.apache.org/job/HBase-1.1-JDK7/1721/])
HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) though (stack:
rev 4b28cd89abea32afd948e3acc1f16106e8cf67f7)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
Revert "HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) (stack:
rev b90d0dec18682dea06bab0b8abde1d92805f2c2c)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15878) Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even though its 'late')
[ https://issues.apache.org/jira/browse/HBASE-15878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297401#comment-15297401 ] Hudson commented on HBASE-15878: FAILURE: Integrated in HBase-1.1-JDK7 #1721 (See [https://builds.apache.org/job/HBase-1.1-JDK7/1721/]) HBASE-15878 Deprecate doBulkLoad(Path hfofDir, final HTable table) in (stack: rev 921ecef3864901e74b8a87f83eb34d1e621ce0ba) * hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java > Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even > though its 'late') > > > Key: HBASE-15878 > URL: https://issues.apache.org/jira/browse/HBASE-15878 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack > Fix For: 1.3.0, 1.2.2, 1.1.6 > > Attachments: 15878.patch > > > The parent issue is about our removing doBulkLoad(Path hfofDir, final HTable > table) in branch-2 even though it did not go through a proper deprecation > cycle. Here we are doing a backfill of deprecations (though it too late for > doBulkLoad(Path hfofDir, final HTable table) to enjoy a proper deprecation > cycle). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15880) RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
[
https://issues.apache.org/jira/browse/HBASE-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297400#comment-15297400
]
Hudson commented on HBASE-15880:
SUCCESS: Integrated in HBase-1.2-IT #517 (See
[https://builds.apache.org/job/HBase-1.2-IT/517/])
HBASE-15880 RpcClientImpl#tracedWriteRequest incorrectly closes HTrace
(antonov: rev 254579893cd123fb8d027e127019649c473e5287)
* hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClientImpl.java
> RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
> ---
>
> Key: HBASE-15880
> URL: https://issues.apache.org/jira/browse/HBASE-15880
> Project: HBase
> Issue Type: Bug
> Components: tracing
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 1.3.0
>
> Attachments: HBASE-15880-branch-1.3.v1.patch
>
>
> In this method we continue the span and then close it, which causes the
> current span (the one created by client app around HTabl#get() or similar API
> call) to be closed incorrectly.
> {code}
> TraceScope ts = Trace.continueSpan(span);
> try {
> writeRequest(call, priority, span);
> } finally {
> ts.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15883) Adding WAL files and tracking offsets in HBase.
[ https://issues.apache.org/jira/browse/HBASE-15883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph updated HBASE-15883: --- Attachment: HBASE-15883.patch > Adding WAL files and tracking offsets in HBase. > > > Key: HBASE-15883 > URL: https://issues.apache.org/jira/browse/HBASE-15883 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Joseph >Assignee: Joseph > Attachments: HBASE-15883.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15880) RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
[
https://issues.apache.org/jira/browse/HBASE-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297373#comment-15297373
]
Hudson commented on HBASE-15880:
FAILURE: Integrated in HBase-Trunk_matrix #943 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/943/])
HBASE-15880 RpcClientImpl#tracedWriteRequest incorrectly closes HTrace
(antonov: rev 1c30ae68ec84447aa27a9c1cb69bfe6b10244984)
* hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClientImpl.java
> RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
> ---
>
> Key: HBASE-15880
> URL: https://issues.apache.org/jira/browse/HBASE-15880
> Project: HBase
> Issue Type: Bug
> Components: tracing
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 1.3.0
>
> Attachments: HBASE-15880-branch-1.3.v1.patch
>
>
> In this method we continue the span and then close it, which causes the
> current span (the one created by client app around HTabl#get() or similar API
> call) to be closed incorrectly.
> {code}
> TraceScope ts = Trace.continueSpan(span);
> try {
> writeRequest(call, priority, span);
> } finally {
> ts.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15806) An endpoint-based export tool
[ https://issues.apache.org/jira/browse/HBASE-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297374#comment-15297374 ] Hudson commented on HBASE-15806: FAILURE: Integrated in HBase-Trunk_matrix #943 (See [https://builds.apache.org/job/HBase-Trunk_matrix/943/]) HBASE-15806 An endpoint-based export tool (ChiaPing Tsai) (tedyu: rev c03ea895c4c9c9fec59e4b9e14280c5b867ff3eb) * hbase-protocol/pom.xml * hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/Export.java * hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestImportExport.java * hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/ExportEndpoint.java * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ExportProtos.java * hbase-protocol/src/main/protobuf/Export.proto > An endpoint-based export tool > - > > Key: HBASE-15806 > URL: https://issues.apache.org/jira/browse/HBASE-15806 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: Experiment.png, HBASE-15806.patch > > > The time for exporting table can be reduced, if we use the endpoint technique > to export the hdfs files by the region server rather than by hbase client. > In my experiments, the elapsed time of endpoint-based export can be less than > half of current export tool (enable the hdfs compression) > But the shortcomings is we need to alter table for deploying the endpoint > any comments about this? thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15867) Move HBase replication tracking from ZooKeeper to HBase
[ https://issues.apache.org/jira/browse/HBASE-15867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297362#comment-15297362 ] Joseph commented on HBASE-15867: Oh ok, sorry I am pretty new to how this works, but what do you mean by go on / work with the other issue? [~eclark] what do you think? > Move HBase replication tracking from ZooKeeper to HBase > --- > > Key: HBASE-15867 > URL: https://issues.apache.org/jira/browse/HBASE-15867 > Project: HBase > Issue Type: New Feature > Components: Replication >Reporter: Joseph >Assignee: Joseph > > Move the WAL file and offset tracking from ZooKeeper into an HBase table for > replication. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-15883) Adding WAL files and tracking offsets in HBase.
[ https://issues.apache.org/jira/browse/HBASE-15883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph reassigned HBASE-15883: -- Assignee: Joseph > Adding WAL files and tracking offsets in HBase. > > > Key: HBASE-15883 > URL: https://issues.apache.org/jira/browse/HBASE-15883 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Joseph >Assignee: Joseph > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15883) Adding WAL files and tracking offsets in HBase.
Joseph created HBASE-15883: -- Summary: Adding WAL files and tracking offsets in HBase. Key: HBASE-15883 URL: https://issues.apache.org/jira/browse/HBASE-15883 Project: HBase Issue Type: Sub-task Reporter: Joseph -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15853) HBase backups fail if there is no /user/hbase directory on HDFS
[
https://issues.apache.org/jira/browse/HBASE-15853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-15853:
---
Status: Open (was: Patch Available)
> HBase backups fail if there is no /user/hbase directory on HDFS
> ---
>
> Key: HBASE-15853
> URL: https://issues.apache.org/jira/browse/HBASE-15853
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Labels: backup
> Fix For: 2.0.0
>
> Attachments: hbase-15853.v1.txt
>
>
> [~cartershanklin] reproted the following issue.
> When running a backup job with no /user/hbase directory created and writable
> to hbase, the job will fail. You have to look in the logs to see the
> specifics of the failure.
> The error is obscure:
> {code}
> 2016-05-18 00:05:42,616 ERROR [main] util.AbstractHBaseTool: Error running
> command-line tool
> java.io.IOException: Failed of exporting snapshot
> snapshot_1463529938818_default_SYSTEM.CATALOG to
> /tmp/backup/backup_1463529938254/default/SYSTEM.CATALOG/ with reason code 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
> at
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
> at
> org.apache.hadoop.hbase.util.ForeignExceptionUtil.toIOException(ForeignExceptionUtil.java:45)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin$TableBackupFuture.convertResult(HBaseAdmin.java:2661)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin$TableBackupFuture.convertResult(HBaseAdmin.java:2640)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin$ProcedureFuture.waitProcedureResult(HBaseAdmin.java:4537)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin$ProcedureFuture.get(HBaseAdmin.java:4471)
> at org.apache.hadoop.hbase.client.HBaseAdmin.get(HBaseAdmin.java:2618)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.backupTables(HBaseAdmin.java:2634)
> at
> org.apache.hadoop.hbase.backup.impl.BackupCommands$CreateCommand.execute(BackupCommands.java:197)
> at
> org.apache.hadoop.hbase.backup.BackupDriver.parseAndRun(BackupDriver.java:107)
> at
> org.apache.hadoop.hbase.backup.BackupDriver.doWork(BackupDriver.java:122)
> at
> org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:112)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76)
> at
> org.apache.hadoop.hbase.backup.BackupDriver.main(BackupDriver.java:127)
> Caused by: org.apache.hadoop.ipc.RemoteException(java.io.IOException): Failed
> of exporting snapshot snapshot_1463529938818_default_SYSTEM.CATALOG to
> /tmp/backup/backup_1463529938254/default/SYSTEM.CATALOG/ with reason code 1
> at
> org.apache.hadoop.hbase.backup.master.FullTableBackupProcedure.snapshotCopy(FullTableBackupProcedure.java:323)
> at
> org.apache.hadoop.hbase.backup.master.FullTableBackupProcedure.executeFromState(FullTableBackupProcedure.java:594)
> at
> org.apache.hadoop.hbase.backup.master.FullTableBackupProcedure.executeFromState(FullTableBackupProcedure.java:68)
> at
> org.apache.hadoop.hbase.procedure2.StateMachineProcedure.execute(StateMachineProcedure.java:107)
> at
> org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:443)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:932)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execLoop(ProcedureExecutor.java:736)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execLoop(ProcedureExecutor.java:689)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.access$200(ProcedureExecutor.java:73)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor$1.run(ProcedureExecutor.java:416)
> {code}
> Here's what ends up in the logs:
> {code}
> 2016-05-18 00:05:41,051 ERROR [ProcedureExecutorThread-1]
> snapshot.ExportSnapshot: Snapshot export failed
> org.apache.hadoop.security.AccessControlException: Permission denied:
> user=hbase, access=WRITE, inode="/user/hbase/.staging":hdfs:hdfs:drwxr-xr-x
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:319)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:292)
> at
>
[jira] [Commented] (HBASE-11819) Unit test for CoprocessorHConnection
[
https://issues.apache.org/jira/browse/HBASE-11819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297332#comment-15297332
]
Hadoop QA commented on HBASE-11819:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
11s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 31s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
1s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
57s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
57s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 58s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 58s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 43s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 43s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
9s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
10m 36s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.1 2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 7s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 104m 51s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 132m 3s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestRegionServerMetrics |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12805593/HBASE-11819v6-master.patch
|
| JIRA Issue | HBASE-11819 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf901.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/test_framework/yetus-0.2.1/lib/precommit/personality/hbase.sh
|
| git revision | master / 1c30ae6 |
| Default Java | 1.7.0_79 |
| Multi-JDK versions | /home/jenkins/tools/java/jdk1.8.0:1.8.0
/usr/local/jenkins/java/jdk1.7.0_79:1.7.0_79 |
| findbugs | v3.0.0 |
| unit |
[jira] [Updated] (HBASE-4368) Expose processlist in shell (per regionserver and perhaps by cluster)
[ https://issues.apache.org/jira/browse/HBASE-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-4368: - Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 1.4.0 2.0.0 Status: Resolved (was: Patch Available) Pushed to branch-1 and to master. Want to write a release note [~talat]? [~mantonov] You want this in 1.3? > Expose processlist in shell (per regionserver and perhaps by cluster) > - > > Key: HBASE-4368 > URL: https://issues.apache.org/jira/browse/HBASE-4368 > Project: HBase > Issue Type: Task > Components: shell >Reporter: stack >Assignee: Talat UYARER > Labels: beginner > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-4368.patch, HBASE-4368v2-withunittest.patch, > HBASE-4368v2.patch, HBASE-4368v3.patch, HBASE-4368v4.patch, > HBASE-4368v5-branch-1.patch > > > HBASE-4057 adds processlist and it shows in the RS UI. This issue is about > getting the processlist to show in the shell, like it does in mysql. > Labelling it noob; this is a pretty substantial issue but it shouldn't be too > hard -- it'd mostly be plumbing from RS into the shell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15882) Upgrade to yetus precommit 0.3.0
Sean Busbey created HBASE-15882: --- Summary: Upgrade to yetus precommit 0.3.0 Key: HBASE-15882 URL: https://issues.apache.org/jira/browse/HBASE-15882 Project: HBase Issue Type: Improvement Components: build Reporter: Sean Busbey Assignee: Sean Busbey Now that Yetus 0.3.0 is out, we should update our precommit builds so we can use docker again. Most of the changes to our personality should be covered in the updated hbase example that ships with 0.3.0. we'll have to forward port the flakey test work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297276#comment-15297276
]
Hudson commented on HBASE-15876:
SUCCESS: Integrated in HBase-1.2 #634 (See
[https://builds.apache.org/job/HBase-1.2/634/])
HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) though (stack:
rev 0f5f4a58acb8a61b8e5118692a060180b7baa5b8)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
Revert "HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) (stack:
rev 94cf956be0e439a628580ac8bb5d900ae5c347ba)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15878) Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even though its 'late')
[ https://issues.apache.org/jira/browse/HBASE-15878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297275#comment-15297275 ] Hudson commented on HBASE-15878: SUCCESS: Integrated in HBase-1.2 #634 (See [https://builds.apache.org/job/HBase-1.2/634/]) HBASE-15878 Deprecate doBulkLoad(Path hfofDir, final HTable table) in (stack: rev 81265624a1edd3321c1715b82703b44b537ff844) * hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java > Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even > though its 'late') > > > Key: HBASE-15878 > URL: https://issues.apache.org/jira/browse/HBASE-15878 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack > Fix For: 1.3.0, 1.2.2, 1.1.6 > > Attachments: 15878.patch > > > The parent issue is about our removing doBulkLoad(Path hfofDir, final HTable > table) in branch-2 even though it did not go through a proper deprecation > cycle. Here we are doing a backfill of deprecations (though it too late for > doBulkLoad(Path hfofDir, final HTable table) to enjoy a proper deprecation > cycle). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-4368) Expose processlist in shell (per regionserver and perhaps by cluster)
[ https://issues.apache.org/jira/browse/HBASE-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297270#comment-15297270 ] stack commented on HBASE-4368: -- Let me commit. I'll scrub the whitespace as part of the commit. Suggest you read this section, http://hbase.apache.org/book.html#developing, especially the bit on making patches [~talat], since you will be contributing so many this summer! > Expose processlist in shell (per regionserver and perhaps by cluster) > - > > Key: HBASE-4368 > URL: https://issues.apache.org/jira/browse/HBASE-4368 > Project: HBase > Issue Type: Task > Components: shell >Reporter: stack >Assignee: Talat UYARER > Labels: beginner > Attachments: HBASE-4368.patch, HBASE-4368v2-withunittest.patch, > HBASE-4368v2.patch, HBASE-4368v3.patch, HBASE-4368v4.patch, > HBASE-4368v5-branch-1.patch > > > HBASE-4057 adds processlist and it shows in the RS UI. This issue is about > getting the processlist to show in the shell, like it does in mysql. > Labelling it noob; this is a pretty substantial issue but it shouldn't be too > hard -- it'd mostly be plumbing from RS into the shell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15881) Allow BZIP2 compression
[ https://issues.apache.org/jira/browse/HBASE-15881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-15881: Component/s: HFile > Allow BZIP2 compression > --- > > Key: HBASE-15881 > URL: https://issues.apache.org/jira/browse/HBASE-15881 > Project: HBase > Issue Type: New Feature > Components: HFile >Reporter: Lars Hofhansl > Attachments: 15881-0.98.txt > > > BZIP2 is a very efficient compressor in terms of compression rate. > Compression speed is very slow, de-compression is equivalent or faster than > GZIP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15880) RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
[
https://issues.apache.org/jira/browse/HBASE-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297231#comment-15297231
]
Hudson commented on HBASE-15880:
FAILURE: Integrated in HBase-1.3 #713 (See
[https://builds.apache.org/job/HBase-1.3/713/])
HBASE-15880 RpcClientImpl#tracedWriteRequest incorrectly closes HTrace
(antonov: rev 37e080d7018c9f5fdddb902f9898c464bbe07028)
* hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClientImpl.java
> RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
> ---
>
> Key: HBASE-15880
> URL: https://issues.apache.org/jira/browse/HBASE-15880
> Project: HBase
> Issue Type: Bug
> Components: tracing
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 1.3.0
>
> Attachments: HBASE-15880-branch-1.3.v1.patch
>
>
> In this method we continue the span and then close it, which causes the
> current span (the one created by client app around HTabl#get() or similar API
> call) to be closed incorrectly.
> {code}
> TraceScope ts = Trace.continueSpan(span);
> try {
> writeRequest(call, priority, span);
> } finally {
> ts.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15881) Allow BZIP2 compression
[ https://issues.apache.org/jira/browse/HBASE-15881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-15881: Issue Type: New Feature (was: Bug) > Allow BZIP2 compression > --- > > Key: HBASE-15881 > URL: https://issues.apache.org/jira/browse/HBASE-15881 > Project: HBase > Issue Type: New Feature >Reporter: Lars Hofhansl > Attachments: 15881-0.98.txt > > > BZIP2 is a very efficient compressor in terms of compression rate. > Compression speed is very slow, de-compression is equivalent or faster than > GZIP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15880) RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
[
https://issues.apache.org/jira/browse/HBASE-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297205#comment-15297205
]
Hudson commented on HBASE-15880:
SUCCESS: Integrated in HBase-1.4 #173 (See
[https://builds.apache.org/job/HBase-1.4/173/])
HBASE-15880 RpcClientImpl#tracedWriteRequest incorrectly closes HTrace
(antonov: rev 51dfe441741272597b0cad45015b2a4c5a226771)
* hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClientImpl.java
> RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
> ---
>
> Key: HBASE-15880
> URL: https://issues.apache.org/jira/browse/HBASE-15880
> Project: HBase
> Issue Type: Bug
> Components: tracing
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 1.3.0
>
> Attachments: HBASE-15880-branch-1.3.v1.patch
>
>
> In this method we continue the span and then close it, which causes the
> current span (the one created by client app around HTabl#get() or similar API
> call) to be closed incorrectly.
> {code}
> TraceScope ts = Trace.continueSpan(span);
> try {
> writeRequest(call, priority, span);
> } finally {
> ts.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297206#comment-15297206
]
Hudson commented on HBASE-15876:
SUCCESS: Integrated in HBase-1.4 #173 (See
[https://builds.apache.org/job/HBase-1.4/173/])
HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) though (stack:
rev 04ef799dd0c67b2bd2ff68bce4dcd99a979a52d6)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
Revert "HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) (stack:
rev 67c02684c9d1feed88d9c9b0fa5210e16e69ac82)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15878) Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even though its 'late')
[ https://issues.apache.org/jira/browse/HBASE-15878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297204#comment-15297204 ] Hudson commented on HBASE-15878: SUCCESS: Integrated in HBase-1.4 #173 (See [https://builds.apache.org/job/HBase-1.4/173/]) HBASE-15878 Deprecate doBulkLoad(Path hfofDir, final HTable table) in (stack: rev e50bf9d7a9eed5a9a02087245f304525373276c4) * hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java > Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even > though its 'late') > > > Key: HBASE-15878 > URL: https://issues.apache.org/jira/browse/HBASE-15878 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack > Fix For: 1.3.0, 1.2.2, 1.1.6 > > Attachments: 15878.patch > > > The parent issue is about our removing doBulkLoad(Path hfofDir, final HTable > table) in branch-2 even though it did not go through a proper deprecation > cycle. Here we are doing a backfill of deprecations (though it too late for > doBulkLoad(Path hfofDir, final HTable table) to enjoy a proper deprecation > cycle). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15837) Memstore size accounting is wrong if postBatchMutate() throws exception
[ https://issues.apache.org/jira/browse/HBASE-15837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297199#comment-15297199 ] Enis Soztutar commented on HBASE-15837: --- Updated the title to reflect the patch. We should commit this for correct accounting. [~elserj] I was not able to find the "submit patch" button. Do you see it? > Memstore size accounting is wrong if postBatchMutate() throws exception > --- > > Key: HBASE-15837 > URL: https://issues.apache.org/jira/browse/HBASE-15837 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0 > > Attachments: HBASE-15837.001.patch, hbase-15837-v1.patch, > hbase-memstore-size-accounting.patch > > > Over in PHOENIX-2883, I've been trying to figure out how to track down the > root cause of an issue we were seeing where a negative memstoreSize was > ultimately causing an RS to abort. The tl;dr version is > * Something causes memstoreSize to be negative (not sure what is doing this > yet) > * All subsequent flushes short-circuit and don't run because they think there > is no data to flush > * The region is eventually closed (commonly, for a move). > * A final flush is attempted on each store before closing (which also > short-circuit for the same reason), leaving unflushed data in each store. > * The sanity check that each store's size is zero fails and the RS aborts. > I have a little patch which I think should improve our failure case around > this, preventing the RS abort safely (forcing a flush when memstoreSize is > negative) and logging a calltrace when an update to memstoreSize make it > negative (to find culprits in the future). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15837) Memstore size accounting is wrong if postBatchMutate() throws exception
[ https://issues.apache.org/jira/browse/HBASE-15837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15837: -- Summary: Memstore size accounting is wrong if postBatchMutate() throws exception (was: More gracefully handle a negative memstoreSize) > Memstore size accounting is wrong if postBatchMutate() throws exception > --- > > Key: HBASE-15837 > URL: https://issues.apache.org/jira/browse/HBASE-15837 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Josh Elser >Assignee: Josh Elser > Fix For: 2.0.0 > > Attachments: HBASE-15837.001.patch, hbase-15837-v1.patch, > hbase-memstore-size-accounting.patch > > > Over in PHOENIX-2883, I've been trying to figure out how to track down the > root cause of an issue we were seeing where a negative memstoreSize was > ultimately causing an RS to abort. The tl;dr version is > * Something causes memstoreSize to be negative (not sure what is doing this > yet) > * All subsequent flushes short-circuit and don't run because they think there > is no data to flush > * The region is eventually closed (commonly, for a move). > * A final flush is attempted on each store before closing (which also > short-circuit for the same reason), leaving unflushed data in each store. > * The sanity check that each store's size is zero fails and the RS aborts. > I have a little patch which I think should improve our failure case around > this, preventing the RS abort safely (forcing a flush when memstoreSize is > negative) and logging a calltrace when an update to memstoreSize make it > negative (to find culprits in the future). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15881) Allow BZIP2 compression
[ https://issues.apache.org/jira/browse/HBASE-15881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297143#comment-15297143 ] Lars Hofhansl commented on HBASE-15881: --- Of course we need to keep concerns such as voice in HBASE-2988 and related in mind with slow compressors. > Allow BZIP2 compression > --- > > Key: HBASE-15881 > URL: https://issues.apache.org/jira/browse/HBASE-15881 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl > Attachments: 15881-0.98.txt > > > BZIP2 is a very efficient compressor in terms of compression rate. > Compression speed is very slow, de-compression is equivalent or faster than > GZIP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15881) Allow BZIP2 compression
[ https://issues.apache.org/jira/browse/HBASE-15881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-15881: -- Attachment: 15881-0.98.txt Trivial patch against 0.98. Will make a trunk patch now. > Allow BZIP2 compression > --- > > Key: HBASE-15881 > URL: https://issues.apache.org/jira/browse/HBASE-15881 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl > Attachments: 15881-0.98.txt > > > BZIP2 is a very efficient compressor in terms of compression rate. > Compression speed is very slow, de-compression is equivalent or faster than > GZIP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15881) Allow BZIP2 compression
Lars Hofhansl created HBASE-15881: - Summary: Allow BZIP2 compression Key: HBASE-15881 URL: https://issues.apache.org/jira/browse/HBASE-15881 Project: HBase Issue Type: Bug Reporter: Lars Hofhansl BZIP2 is a very efficient compressor in terms of compression rate. Compression speed is very slow, de-compression is equivalent or faster than GZIP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-4368) Expose processlist in shell (per regionserver and perhaps by cluster)
[ https://issues.apache.org/jira/browse/HBASE-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297114#comment-15297114 ] stack commented on HBASE-4368: -- I tried it by RS too. Seems to work. > Expose processlist in shell (per regionserver and perhaps by cluster) > - > > Key: HBASE-4368 > URL: https://issues.apache.org/jira/browse/HBASE-4368 > Project: HBase > Issue Type: Task > Components: shell >Reporter: stack >Assignee: Talat UYARER > Labels: beginner > Attachments: HBASE-4368.patch, HBASE-4368v2-withunittest.patch, > HBASE-4368v2.patch, HBASE-4368v3.patch, HBASE-4368v4.patch, > HBASE-4368v5-branch-1.patch > > > HBASE-4057 adds processlist and it shows in the RS UI. This issue is about > getting the processlist to show in the shell, like it does in mysql. > Labelling it noob; this is a pretty substantial issue but it shouldn't be too > hard -- it'd mostly be plumbing from RS into the shell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-4368) Expose processlist in shell (per regionserver and perhaps by cluster)
[ https://issues.apache.org/jira/browse/HBASE-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297110#comment-15297110 ] stack commented on HBASE-4368: -- Path LGTM. Let me get a hadoopqa run in to make sure it doesn't break anything. > Expose processlist in shell (per regionserver and perhaps by cluster) > - > > Key: HBASE-4368 > URL: https://issues.apache.org/jira/browse/HBASE-4368 > Project: HBase > Issue Type: Task > Components: shell >Reporter: stack >Assignee: Talat UYARER > Labels: beginner > Attachments: HBASE-4368.patch, HBASE-4368v2-withunittest.patch, > HBASE-4368v2.patch, HBASE-4368v3.patch, HBASE-4368v4.patch, > HBASE-4368v5-branch-1.patch > > > HBASE-4057 adds processlist and it shows in the RS UI. This issue is about > getting the processlist to show in the shell, like it does in mysql. > Labelling it noob; this is a pretty substantial issue but it shouldn't be too > hard -- it'd mostly be plumbing from RS into the shell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-4368) Expose processlist in shell (per regionserver and perhaps by cluster)
[
https://issues.apache.org/jira/browse/HBASE-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297106#comment-15297106
]
Hadoop QA commented on HBASE-4368:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} rubocop {color} | {color:blue} 0m 1s
{color} | {color:blue} rubocop was not available. {color} |
| {color:blue}0{color} | {color:blue} ruby-lint {color} | {color:blue} 0m 1s
{color} | {color:blue} Ruby-lint was not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
16s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 21s
{color} | {color:green} branch-1 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 15s
{color} | {color:green} branch-1 passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
17s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
23s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 0s
{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 22s
{color} | {color:green} branch-1 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 11s
{color} | {color:green} branch-1 passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 21s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 21s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 13s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 13s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
8s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 22 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 4m
21s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 0s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 17s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 8s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 15s
{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
9s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 12m 42s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12805574/HBASE-4368v5-branch-1.patch
|
| JIRA Issue | HBASE-4368 |
| Optional Tests | asflicense javac javadoc unit rubocop ruby_lint
findbugs hadoopcheck hbaseanti checkstyle compile |
| uname | Linux asf909.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HBASE-4368) Expose processlist in shell (per regionserver and perhaps by cluster)
[
https://issues.apache.org/jira/browse/HBASE-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297098#comment-15297098
]
stack commented on HBASE-4368:
--
Looks good:
{code}
hbase(main):018:0> processlist
44 tasks as of: 2016-05-23 14:14:15
+-+-+--+--+--+
| Host| Start Time | State| Description
| Status |
+-+-+--+--+--+
| ve0528.halxg... | 2016-05-23 14:13:48 | COMPLETE | Initializing region
hbase:met... | Region opened successfully (since... |
+-+-+--+--+--+
| ve0528.halxg... | 2016-05-23 14:13:51 | COMPLETE | Initializing region
tsdb,\x00... | Region opened successfully (since... |
+-+-+--+--+--+
| ve0528.halxg... | 2016-05-23 14:13:51 | COMPLETE | Initializing region
tsdb,\x00... | Region opened successfully (since... |
+-+-+--+--+--+
| ve0528.halxg... | 2016-05-23 14:13:51 | COMPLETE | Initializing region
tsdb,\x00... | Region opened successfully (since... |
+-+-+--+--+--+
| ve0528.halxg... | 2016-05-23 14:13:51 | COMPLETE | Initializing region
ycsb,user... | Region opened successfully (since... |
+-+-+--+--+--+
| ve0528.halxg... | 2016-05-23 14:13:51 | COMPLETE | Compacting t in
tsdb,\x00\x00... | Compaction complete (since 21 sec... |
+-+-+--+--+--+
| ve0528.halxg... | 2016-05-23 14:13:51 | COMPLETE | Compacting t in
tsdb,\x00\x01... | Compaction complete (since 23 sec... |
+-+-+--+--+--+
| ve0528.halxg... | 2016-05-23 14:13:51 | COMPLETE | Initializing region
tsdb,\x00... | Region opened successfully (since... |
+-+-+--+--+--+
...
{code}
If an idle cluster, it shows nothing which makes sense I suppose. Then if
master is initializing, it dumps out master initializing exception ... which is
ok too.
> Expose processlist in shell (per regionserver and perhaps by cluster)
> -
>
> Key: HBASE-4368
> URL: https://issues.apache.org/jira/browse/HBASE-4368
> Project: HBase
> Issue Type: Task
> Components: shell
>Reporter: stack
>Assignee: Talat UYARER
> Labels: beginner
> Attachments: HBASE-4368.patch, HBASE-4368v2-withunittest.patch,
> HBASE-4368v2.patch, HBASE-4368v3.patch, HBASE-4368v4.patch,
> HBASE-4368v5-branch-1.patch
>
>
> HBASE-4057 adds processlist and it shows in the RS UI. This issue is about
> getting the processlist to show in the shell, like it does in mysql.
> Labelling it noob; this is a pretty substantial issue but it shouldn't be too
> hard -- it'd mostly be plumbing from RS into the shell.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-10358) Shell changes for setting consistency per request
[ https://issues.apache.org/jira/browse/HBASE-10358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] yi liang updated HBASE-10358: - Assignee: yi liang (was: Enis Soztutar) > Shell changes for setting consistency per request > - > > Key: HBASE-10358 > URL: https://issues.apache.org/jira/browse/HBASE-10358 > Project: HBase > Issue Type: New Feature > Components: shell >Reporter: Enis Soztutar >Assignee: yi liang > Fix For: 2.0.0 > > Attachments: Screen Shot 2016-04-21 at 3.09.52 PM.png, Screen Shot > 2016-05-05 at 10.38.27 AM.png, shell.patch, shell_3.patch > > > We can add shell support to set consistency per request. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-4368) Expose processlist in shell (per regionserver and perhaps by cluster)
[ https://issues.apache.org/jira/browse/HBASE-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-4368: - Status: Patch Available (was: Open) > Expose processlist in shell (per regionserver and perhaps by cluster) > - > > Key: HBASE-4368 > URL: https://issues.apache.org/jira/browse/HBASE-4368 > Project: HBase > Issue Type: Task > Components: shell >Reporter: stack >Assignee: Talat UYARER > Labels: beginner > Attachments: HBASE-4368.patch, HBASE-4368v2-withunittest.patch, > HBASE-4368v2.patch, HBASE-4368v3.patch, HBASE-4368v4.patch, > HBASE-4368v5-branch-1.patch > > > HBASE-4057 adds processlist and it shows in the RS UI. This issue is about > getting the processlist to show in the shell, like it does in mysql. > Labelling it noob; this is a pretty substantial issue but it shouldn't be too > hard -- it'd mostly be plumbing from RS into the shell. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14126) I'm using play framework, creating a sample Hbase project. And I keep getting this error: tried to access method com.google.common.base.Stopwatch.()V from class
[ https://issues.apache.org/jira/browse/HBASE-14126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297078#comment-15297078 ] stack commented on HBASE-14126: --- [~Kwon Ohsang] ask on the mailing list rather than here? Related is HBASE-14963. See the [~jingcheng...@intel.com] suggestion above? > I'm using play framework, creating a sample Hbase project. And I keep getting > this error: tried to access method com.google.common.base.Stopwatch.()V > from class org.apache.hadoop.hbase.zookeeper.MetaTableLocator > - > > Key: HBASE-14126 > URL: https://issues.apache.org/jira/browse/HBASE-14126 > Project: HBase > Issue Type: Task > Environment: Ubuntu; Play Framework 2.4.2; Hbase 1.0 >Reporter: Lesley Cheung > > The simple Hbase project works in Maven. But when I use play framework , it > keeps showing this error. I modified the lib dependency many times, but I > just can't eliminate this error. Some one please help me! > > java.lang.IllegalAccessError: tried to access method > com.google.common.base.Stopwatch.()V from class > org.apache.hadoop.hbase.zookeeper.MetaTableLocator > at > org.apache.hadoop.hbase.zookeeper.MetaTableLocator.blockUntilAvailable(MetaTableLocator.java:434) > at > org.apache.hadoop.hbase.client.ZooKeeperRegistry.getMetaRegionLocation(ZooKeeperRegistry.java:60) > at > org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegion(ConnectionManager.java:1123) > at > org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegion(ConnectionManager.java:1110) > at > org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegionInMeta(ConnectionManager.java:1262) > at > org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegion(ConnectionManager.java:1126) > at > org.apache.hadoop.hbase.client.AsyncProcess.submit(AsyncProcess.java:369) > at > org.apache.hadoop.hbase.client.AsyncProcess.submit(AsyncProcess.java:320) > at > org.apache.hadoop.hbase.client.BufferedMutatorImpl.backgroundFlushCommits(BufferedMutatorImpl.java:206) > at > org.apache.hadoop.hbase.client.BufferedMutatorImpl.flush(BufferedMutatorImpl.java:183) > at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1496) > at org.apache.hadoop.hbase.client.HTable.put(HTable.java:1119) > at utils.BigQueue.run(BigQueue.java:68) > at > akka.actor.LightArrayRevolverScheduler$$anon$2$$anon$1.run(Scheduler.scala:242) > at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:41) > at > akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:393) > at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260) > at > scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339) > at > scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) > at > scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-11819) Unit test for CoprocessorHConnection
[ https://issues.apache.org/jira/browse/HBASE-11819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-11819: -- Status: Patch Available (was: Open) Submit to get a run in. > Unit test for CoprocessorHConnection > - > > Key: HBASE-11819 > URL: https://issues.apache.org/jira/browse/HBASE-11819 > Project: HBase > Issue Type: Test >Reporter: Andrew Purtell >Assignee: Talat UYARER >Priority: Minor > Labels: beginner > Fix For: 2.0.0, 1.3.0, 1.2.2, 1.1.6, 0.98.14 > > Attachments: HBASE-11819v4-master.patch, HBASE-11819v5-0.98 > (1).patch, HBASE-11819v5-0.98.patch, HBASE-11819v5-master (1).patch, > HBASE-11819v5-master.patch, HBASE-11819v5-master.patch, > HBASE-11819v5-v0.98.patch, HBASE-11819v5-v1.0.patch, > HBASE-11819v6-branch-1.patch, HBASE-11819v6-master.patch > > > Add a unit test to hbase-server that exercises CoprocessorHConnection . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-11819) Unit test for CoprocessorHConnection
[ https://issues.apache.org/jira/browse/HBASE-11819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297072#comment-15297072 ] stack commented on HBASE-11819: --- [~talat] make the formatting the same as for other code -- i.e. no tabs and tabstops = 2spaces rather than 4. > Unit test for CoprocessorHConnection > - > > Key: HBASE-11819 > URL: https://issues.apache.org/jira/browse/HBASE-11819 > Project: HBase > Issue Type: Test >Reporter: Andrew Purtell >Assignee: Talat UYARER >Priority: Minor > Labels: beginner > Fix For: 2.0.0, 0.98.14, 1.3.0, 1.2.2, 1.1.6 > > Attachments: HBASE-11819v4-master.patch, HBASE-11819v5-0.98 > (1).patch, HBASE-11819v5-0.98.patch, HBASE-11819v5-master (1).patch, > HBASE-11819v5-master.patch, HBASE-11819v5-master.patch, > HBASE-11819v5-v0.98.patch, HBASE-11819v5-v1.0.patch, > HBASE-11819v6-branch-1.patch, HBASE-11819v6-master.patch > > > Add a unit test to hbase-server that exercises CoprocessorHConnection . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15880) RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
[
https://issues.apache.org/jira/browse/HBASE-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296986#comment-15296986
]
Mikhail Antonov commented on HBASE-15880:
-
Pushed branch-1.2
> RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
> ---
>
> Key: HBASE-15880
> URL: https://issues.apache.org/jira/browse/HBASE-15880
> Project: HBase
> Issue Type: Bug
> Components: tracing
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 1.3.0
>
> Attachments: HBASE-15880-branch-1.3.v1.patch
>
>
> In this method we continue the span and then close it, which causes the
> current span (the one created by client app around HTabl#get() or similar API
> call) to be closed incorrectly.
> {code}
> TraceScope ts = Trace.continueSpan(span);
> try {
> writeRequest(call, priority, span);
> } finally {
> ts.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15880) RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
[
https://issues.apache.org/jira/browse/HBASE-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296976#comment-15296976
]
Sean Busbey commented on HBASE-15880:
-
+1 for branch-1.2
> RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
> ---
>
> Key: HBASE-15880
> URL: https://issues.apache.org/jira/browse/HBASE-15880
> Project: HBase
> Issue Type: Bug
> Components: tracing
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 1.3.0
>
> Attachments: HBASE-15880-branch-1.3.v1.patch
>
>
> In this method we continue the span and then close it, which causes the
> current span (the one created by client app around HTabl#get() or similar API
> call) to be closed incorrectly.
> {code}
> TraceScope ts = Trace.continueSpan(span);
> try {
> writeRequest(call, priority, span);
> } finally {
> ts.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15878) Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even though its 'late')
[ https://issues.apache.org/jira/browse/HBASE-15878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296959#comment-15296959 ] Hudson commented on HBASE-15878: SUCCESS: Integrated in HBase-1.2-IT #516 (See [https://builds.apache.org/job/HBase-1.2-IT/516/]) HBASE-15878 Deprecate doBulkLoad(Path hfofDir, final HTable table) in (stack: rev 81265624a1edd3321c1715b82703b44b537ff844) * hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java > Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even > though its 'late') > > > Key: HBASE-15878 > URL: https://issues.apache.org/jira/browse/HBASE-15878 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack > Fix For: 1.3.0, 1.2.2, 1.1.6 > > Attachments: 15878.patch > > > The parent issue is about our removing doBulkLoad(Path hfofDir, final HTable > table) in branch-2 even though it did not go through a proper deprecation > cycle. Here we are doing a backfill of deprecations (though it too late for > doBulkLoad(Path hfofDir, final HTable table) to enjoy a proper deprecation > cycle). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-15880) RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
[
https://issues.apache.org/jira/browse/HBASE-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Antonov resolved HBASE-15880.
-
Resolution: Fixed
> RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
> ---
>
> Key: HBASE-15880
> URL: https://issues.apache.org/jira/browse/HBASE-15880
> Project: HBase
> Issue Type: Bug
> Components: tracing
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 1.3.0
>
> Attachments: HBASE-15880-branch-1.3.v1.patch
>
>
> In this method we continue the span and then close it, which causes the
> current span (the one created by client app around HTabl#get() or similar API
> call) to be closed incorrectly.
> {code}
> TraceScope ts = Trace.continueSpan(span);
> try {
> writeRequest(call, priority, span);
> } finally {
> ts.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15880) RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
[
https://issues.apache.org/jira/browse/HBASE-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296972#comment-15296972
]
Mikhail Antonov commented on HBASE-15880:
-
Thanks [~stack], committed to master, branch-1 and branch-1.3. [~busbey],
[~ndimiduk] ?
> RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
> ---
>
> Key: HBASE-15880
> URL: https://issues.apache.org/jira/browse/HBASE-15880
> Project: HBase
> Issue Type: Bug
> Components: tracing
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 1.3.0
>
> Attachments: HBASE-15880-branch-1.3.v1.patch
>
>
> In this method we continue the span and then close it, which causes the
> current span (the one created by client app around HTabl#get() or similar API
> call) to be closed incorrectly.
> {code}
> TraceScope ts = Trace.continueSpan(span);
> try {
> writeRequest(call, priority, span);
> } finally {
> ts.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15879) Introduce Key interface
[
https://issues.apache.org/jira/browse/HBASE-15879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296971#comment-15296971
]
stack commented on HBASE-15879:
---
Shouldn't fact that a Key implementation is made of contiguous bytes be an
implementation detail? And if we are saving copies by doubling down on the KV
backed by a byte array, I'd rather we just did the copies?
Our poor KeyValue must be buckling under the weight of all the Interfaces it
implements:
public class KeyValue implements Cell, HeapSize, Cloneable, SettableSequenceId,
SettableTimestamp, Streamable, ContiguousKey {
Are we not able to remove some Interfaces?
> Introduce Key interface
> ---
>
> Key: HBASE-15879
> URL: https://issues.apache.org/jira/browse/HBASE-15879
> Project: HBase
> Issue Type: Improvement
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Attachments: HBASE-15879.patch
>
>
> Introduce an interface called Key and allow Cell implementations to implement
> this Key interface for cases like KeyValue, OffheapKeyValue and DBE cells
> (Except prefix tree) so that we can avoid copies when we deal with only Cells
> in case of block index creations (like ROOT, Bloom etc). Helps in reduction
> of garbage also.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296960#comment-15296960
]
Hudson commented on HBASE-15876:
SUCCESS: Integrated in HBase-1.2-IT #516 (See
[https://builds.apache.org/job/HBase-1.2-IT/516/])
HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) though (stack:
rev 0f5f4a58acb8a61b8e5118692a060180b7baa5b8)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
Revert "HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) (stack:
rev 94cf956be0e439a628580ac8bb5d900ae5c347ba)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15806) An endpoint-based export tool
[ https://issues.apache.org/jira/browse/HBASE-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296957#comment-15296957 ] ChiaPing Tsai commented on HBASE-15806: --- I don't profile all the phase but I measure the total job elapsed time (as [attached|https://issues.apache.org/jira/secure/attachment/12805500/Experiment.png]). The endpoint approach and MR approach have many similarities as following: 1) same arguments (scan and output options) 2) same split(one region one split) 3) same output (sequence file) The factor that impacts the performance is the endpoint approach doesn't transfer data from regionserver to client (save rpc), so the endpoint apprache will be faster than MR approach (if the data output is not bottleneck) Sincerely > An endpoint-based export tool > - > > Key: HBASE-15806 > URL: https://issues.apache.org/jira/browse/HBASE-15806 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: Experiment.png, HBASE-15806.patch > > > The time for exporting table can be reduced, if we use the endpoint technique > to export the hdfs files by the region server rather than by hbase client. > In my experiments, the elapsed time of endpoint-based export can be less than > half of current export tool (enable the hdfs compression) > But the shortcomings is we need to alter table for deploying the endpoint > any comments about this? thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15880) RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
[
https://issues.apache.org/jira/browse/HBASE-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296923#comment-15296923
]
stack commented on HBASE-15880:
---
+1
> RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
> ---
>
> Key: HBASE-15880
> URL: https://issues.apache.org/jira/browse/HBASE-15880
> Project: HBase
> Issue Type: Bug
> Components: tracing
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 1.3.0
>
> Attachments: HBASE-15880-branch-1.3.v1.patch
>
>
> In this method we continue the span and then close it, which causes the
> current span (the one created by client app around HTabl#get() or similar API
> call) to be closed incorrectly.
> {code}
> TraceScope ts = Trace.continueSpan(span);
> try {
> writeRequest(call, priority, span);
> } finally {
> ts.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296922#comment-15296922
]
Hudson commented on HBASE-15876:
FAILURE: Integrated in HBase-Trunk_matrix #942 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/942/])
HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) though (stack:
rev 7130a222ce6a70ef14f1eae6c3f06a52ba4b63de)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mob/compactions/PartitionedMobCompactor.java
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15879) Introduce Key interface
[
https://issues.apache.org/jira/browse/HBASE-15879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296917#comment-15296917
]
Hadoop QA commented on HBASE-15879:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 26s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 18s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
29s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
10s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 18s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
19s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 26s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 26s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 18s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 18s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
24s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
10s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 9m
39s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 1s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 24s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 17s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 49s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
10s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 22m 5s {color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12805713/HBASE-15879.patch |
| JIRA Issue | HBASE-15879 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf909.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/test_framework/yetus-0.2.1/lib/precommit/personality/hbase.sh
|
| git revision | master / c03ea89 |
| Default Java | 1.7.0_79 |
| Multi-JDK versions | /home/jenkins/tools/java/jdk1.8.0:1.8.0
/usr/local/jenkins/java/jdk1.7.0_79:1.7.0_79 |
| findbugs | v3.0.0 |
| Test
[jira] [Updated] (HBASE-15880) RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
[
https://issues.apache.org/jira/browse/HBASE-15880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Antonov updated HBASE-15880:
Attachment: HBASE-15880-branch-1.3.v1.patch
> RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
> ---
>
> Key: HBASE-15880
> URL: https://issues.apache.org/jira/browse/HBASE-15880
> Project: HBase
> Issue Type: Bug
> Components: tracing
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 1.3.0
>
> Attachments: HBASE-15880-branch-1.3.v1.patch
>
>
> In this method we continue the span and then close it, which causes the
> current span (the one created by client app around HTabl#get() or similar API
> call) to be closed incorrectly.
> {code}
> TraceScope ts = Trace.continueSpan(span);
> try {
> writeRequest(call, priority, span);
> } finally {
> ts.close();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15878) Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even though its 'late')
[ https://issues.apache.org/jira/browse/HBASE-15878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296887#comment-15296887 ] Hudson commented on HBASE-15878: SUCCESS: Integrated in HBase-1.3-IT #675 (See [https://builds.apache.org/job/HBase-1.3-IT/675/]) HBASE-15878 Deprecate doBulkLoad(Path hfofDir, final HTable table) in (stack: rev 53dd0aeff3732aa4124a8f863fdb0dcd9bbf0ed0) * hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java > Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even > though its 'late') > > > Key: HBASE-15878 > URL: https://issues.apache.org/jira/browse/HBASE-15878 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack > Fix For: 1.3.0, 1.2.2, 1.1.6 > > Attachments: 15878.patch > > > The parent issue is about our removing doBulkLoad(Path hfofDir, final HTable > table) in branch-2 even though it did not go through a proper deprecation > cycle. Here we are doing a backfill of deprecations (though it too late for > doBulkLoad(Path hfofDir, final HTable table) to enjoy a proper deprecation > cycle). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296888#comment-15296888
]
Hudson commented on HBASE-15876:
SUCCESS: Integrated in HBase-1.3-IT #675 (See
[https://builds.apache.org/job/HBase-1.3-IT/675/])
HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) though (stack:
rev e3e3b64ecdae162e8c533de12f7de1508a2219a1)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
Revert "HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) (stack:
rev 39c1f795ee13a6c1edd198ce1b026c0ef6be62a7)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-15880) RpcClientImpl#tracedWriteRequest incorrectly closes HTrace span
Mikhail Antonov created HBASE-15880:
---
Summary: RpcClientImpl#tracedWriteRequest incorrectly closes
HTrace span
Key: HBASE-15880
URL: https://issues.apache.org/jira/browse/HBASE-15880
Project: HBase
Issue Type: Bug
Components: tracing
Affects Versions: 1.2.1, 1.3.0
Reporter: Mikhail Antonov
Assignee: Mikhail Antonov
Fix For: 1.3.0
In this method we continue the span and then close it, which causes the current
span (the one created by client app around HTabl#get() or similar API call) to
be closed incorrectly.
{code}
TraceScope ts = Trace.continueSpan(span);
try {
writeRequest(call, priority, span);
} finally {
ts.close();
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15806) An endpoint-based export tool
[ https://issues.apache.org/jira/browse/HBASE-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296885#comment-15296885 ] Devaraj Das commented on HBASE-15806: - Any quantification on how much computational overhead it brings to the regionservers vis-a-vis the MR approach? > An endpoint-based export tool > - > > Key: HBASE-15806 > URL: https://issues.apache.org/jira/browse/HBASE-15806 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: Experiment.png, HBASE-15806.patch > > > The time for exporting table can be reduced, if we use the endpoint technique > to export the hdfs files by the region server rather than by hbase client. > In my experiments, the elapsed time of endpoint-based export can be less than > half of current export tool (enable the hdfs compression) > But the shortcomings is we need to alter table for deploying the endpoint > any comments about this? thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15879) Introduce Key interface
[ https://issues.apache.org/jira/browse/HBASE-15879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-15879: --- Attachment: HBASE-15879.patch Named the Key interface as ContiguousKey. Is it a better name? REason was to say explicitly that this interface represents formats where the key is really contiguous rather than the need to form a key out of it. KeyValue, OffheapKV, DBE cells (Onheap and OffheapCell) implement this new interface. > Introduce Key interface > --- > > Key: HBASE-15879 > URL: https://issues.apache.org/jira/browse/HBASE-15879 > Project: HBase > Issue Type: Improvement >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Attachments: HBASE-15879.patch > > > Introduce an interface called Key and allow Cell implementations to implement > this Key interface for cases like KeyValue, OffheapKeyValue and DBE cells > (Except prefix tree) so that we can avoid copies when we deal with only Cells > in case of block index creations (like ROOT, Bloom etc). Helps in reduction > of garbage also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15879) Introduce Key interface
[ https://issues.apache.org/jira/browse/HBASE-15879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-15879: --- Status: Patch Available (was: Open) > Introduce Key interface > --- > > Key: HBASE-15879 > URL: https://issues.apache.org/jira/browse/HBASE-15879 > Project: HBase > Issue Type: Improvement >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Attachments: HBASE-15879.patch > > > Introduce an interface called Key and allow Cell implementations to implement > this Key interface for cases like KeyValue, OffheapKeyValue and DBE cells > (Except prefix tree) so that we can avoid copies when we deal with only Cells > in case of block index creations (like ROOT, Bloom etc). Helps in reduction > of garbage also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15525) OutOfMemory could occur when using BoundedByteBufferPool during RPC bursts
[ https://issues.apache.org/jira/browse/HBASE-15525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296862#comment-15296862 ] Anoop Sam John commented on HBASE-15525: I wanted to get it logged in INFO level at least once. So will add extra check. In life of one RS run, it will log one time with INFO level and all remaining in debug level. Sound ok? > OutOfMemory could occur when using BoundedByteBufferPool during RPC bursts > -- > > Key: HBASE-15525 > URL: https://issues.apache.org/jira/browse/HBASE-15525 > Project: HBase > Issue Type: Sub-task > Components: IPC/RPC >Reporter: deepankar >Assignee: Anoop Sam John >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-15525_V1.patch, HBASE-15525_V2.patch, > HBASE-15525_V3.patch, HBASE-15525_WIP.patch, WIP.patch > > > After HBASE-13819 the system some times run out of direct memory whenever > there is some network congestion or some client side issues. > This was because of pending RPCs in the RPCServer$Connection.responseQueue > and since all the responses in this queue hold a buffer for cellblock from > BoundedByteBufferPool this could takeup a lot of memory if the > BoundedByteBufferPool's moving average settles down towards a higher value > See the discussion here > [HBASE-13819-comment|https://issues.apache.org/jira/browse/HBASE-13819?focusedCommentId=15207822=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15207822] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15830) Sasl encryption doesn't work with AsyncRpcChannelImpl
[
https://issues.apache.org/jira/browse/HBASE-15830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296824#comment-15296824
]
Gary Helmling commented on HBASE-15830:
---
Sorry for the delay in the reivew. A couple comments on the patch:
* please rename {{startHbaseConnectionWithEncryption(Channel ch)}} to just
{{startConnectionWithEncryption(Channel ch)}}. The extra "HBase" is
extraneous. I realize that the corresponding {{startHBaseConnection()}} method
is already named this way, but there is no need to continue it.
* in {{getChannelHeaderBytes(AuthMethod authMethod)}}, why not use
IPCUtil.getTotalSizeWhenWrittenDelimited() instead of hard-coding the extra 4
bytes?
* in {{SaslClientHandler}}, please avoid the whitespace-only / formatting
changes. These make it harder to trace actual code changes over time. Unless
you're making a substantive change to the line itself, these should not be
necessary.
* in {{SaslClientHandler.channelRead()}}:
{code}
if (!useWrap) {
ctx.pipeline().remove(this);
successfulConnectHandler.onSuccess(ctx.channel());
} else {
byte[] wrappedCH = saslClient.wrap(connectionHeader, 0,
connectionHeader.length);
// write connection header
writeSaslToken(ctx, wrappedCH);
successfulConnectHandler.onSaslProtectionSucess(ctx.channel());
}
{code}
It looks like we only write the connection header when qop != auth. Is this
right? Don't we need to write the connection header in both cases?
Have you tested this on a secure cluster with the different QoP configs (at
least auth vs conf)?
> Sasl encryption doesn't work with AsyncRpcChannelImpl
> -
>
> Key: HBASE-15830
> URL: https://issues.apache.org/jira/browse/HBASE-15830
> Project: HBase
> Issue Type: Bug
>Reporter: Colin Ma
> Attachments: HBASE-15830.001.patch, HBASE-15830.002.patch
>
>
> Currently, sasl encryption doesn't work with AsyncRpcChannelImpl, there has 3
> problems:
> 1.
> [sourcecode|https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/security/SaslClientHandler.java#L308]
> will throw the following exception:
> java.lang.UnsupportedOperationException: direct buffer
> at
> io.netty.buffer.UnpooledUnsafeDirectByteBuf.array(UnpooledUnsafeDirectByteBuf.java:199)
> at
> org.apache.hadoop.hbase.security.SaslClientHandler.write(SaslClientHandler.java:308)
> 2.
> [sourcecode|https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/AsyncRpcChannelImpl.java#L212]
> has deadlocks problem.
> 3. TestAsyncSecureIPC doesn't cover the sasl encryption test case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296807#comment-15296807
]
Hudson commented on HBASE-15876:
SUCCESS: Integrated in HBase-1.3 #712 (See
[https://builds.apache.org/job/HBase-1.3/712/])
HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) though (stack:
rev e3e3b64ecdae162e8c533de12f7de1508a2219a1)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
Revert "HBASE-15876 Remove doBulkLoad(Path hfofDir, final HTable table) (stack:
rev 39c1f795ee13a6c1edd198ce1b026c0ef6be62a7)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15878) Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even though its 'late')
[ https://issues.apache.org/jira/browse/HBASE-15878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296806#comment-15296806 ] Hudson commented on HBASE-15878: SUCCESS: Integrated in HBase-1.3 #712 (See [https://builds.apache.org/job/HBase-1.3/712/]) HBASE-15878 Deprecate doBulkLoad(Path hfofDir, final HTable table) in (stack: rev 53dd0aeff3732aa4124a8f863fdb0dcd9bbf0ed0) * hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java > Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even > though its 'late') > > > Key: HBASE-15878 > URL: https://issues.apache.org/jira/browse/HBASE-15878 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack > Fix For: 1.3.0, 1.2.2, 1.1.6 > > Attachments: 15878.patch > > > The parent issue is about our removing doBulkLoad(Path hfofDir, final HTable > table) in branch-2 even though it did not go through a proper deprecation > cycle. Here we are doing a backfill of deprecations (though it too late for > doBulkLoad(Path hfofDir, final HTable table) to enjoy a proper deprecation > cycle). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15879) Introduce Key interface
ramkrishna.s.vasudevan created HBASE-15879: -- Summary: Introduce Key interface Key: HBASE-15879 URL: https://issues.apache.org/jira/browse/HBASE-15879 Project: HBase Issue Type: Improvement Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Introduce an interface called Key and allow Cell implementations to implement this Key interface for cases like KeyValue, OffheapKeyValue and DBE cells (Except prefix tree) so that we can avoid copies when we deal with only Cells in case of block index creations (like ROOT, Bloom etc). Helps in reduction of garbage also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15806) An endpoint-based export tool
[ https://issues.apache.org/jira/browse/HBASE-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15806: --- Hadoop Flags: Reviewed > An endpoint-based export tool > - > > Key: HBASE-15806 > URL: https://issues.apache.org/jira/browse/HBASE-15806 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: Experiment.png, HBASE-15806.patch > > > The time for exporting table can be reduced, if we use the endpoint technique > to export the hdfs files by the region server rather than by hbase client. > In my experiments, the elapsed time of endpoint-based export can be less than > half of current export tool (enable the hdfs compression) > But the shortcomings is we need to alter table for deploying the endpoint > any comments about this? thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296685#comment-15296685
]
stack commented on HBASE-15876:
---
I tried to get it to fail for me locally but can't. It is in the flakies set
here:
https://builds.apache.org/view/H-L/view/HBase/job/HBase-Find-Flaky-Tests/lastSuccessfulBuild/artifact/includes/*view*/
I committed it.
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-15876:
--
Resolution: Fixed
Hadoop Flags: Incompatible change,Reviewed
Status: Resolved (was: Patch Available)
Pushed to master. Thanks for the patch [~jurmous]
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15554) StoreFile$Writer.appendGeneralBloomFilter generates extra KV
[ https://issues.apache.org/jira/browse/HBASE-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296638#comment-15296638 ] ramkrishna.s.vasudevan commented on HBASE-15554: Yes. +1 for a new issue and introduce this Key interface. And then use that interface for all the subsequent JIRAs under that. > StoreFile$Writer.appendGeneralBloomFilter generates extra KV > > > Key: HBASE-15554 > URL: https://issues.apache.org/jira/browse/HBASE-15554 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: Vladimir Rodionov >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0 > > Attachments: HBASE-15554.patch, HBASE-15554_3.patch, > HBASE-15554_4.patch > > > Accounts for 10% memory allocation in compaction thread when BloomFilterType > is ROWCOL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-15876:
--
Release Note:
Removes a doBulkLoad method though it has not been through a full deprecation
cycle (but it is 'damaged' because it has a parameter that has been properly
deprecated). Use the alternative {code}public void doBulkLoad(Path hfofDir,
final Admin admin, Table table, RegionLocator regionLocator){code}
See
http://mail-archives.apache.org/mod_mbox/hbase-dev/201605.mbox/%3CCAMUu0w-ZiLoLBLO3D76=n3AjUr=vmttueya28welhyeq8+e...@mail.gmail.com%3E
for NOTICE on this 'premature' removal.
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296585#comment-15296585
]
stack commented on HBASE-15876:
---
Discussion on this removal is on this thread:
"http://mail-archives.apache.org/mod_mbox/hbase-dev/201605.mbox/%3CCAMUu0w-ZiLoLBLO3D76=n3AjUr=vmttueya28welhyeq8+e...@mail.gmail.com%3E;
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (HBASE-15878) Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even though its 'late')
[ https://issues.apache.org/jira/browse/HBASE-15878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-15878. --- Resolution: Fixed Assignee: stack Fix Version/s: (was: 2.0.0) 1.1.6 1.2.2 1.3.0 > Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even > though its 'late') > > > Key: HBASE-15878 > URL: https://issues.apache.org/jira/browse/HBASE-15878 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack > Fix For: 1.3.0, 1.2.2, 1.1.6 > > Attachments: 15878.patch > > > The parent issue is about our removing doBulkLoad(Path hfofDir, final HTable > table) in branch-2 even though it did not go through a proper deprecation > cycle. Here we are doing a backfill of deprecations (though it too late for > doBulkLoad(Path hfofDir, final HTable table) to enjoy a proper deprecation > cycle). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15878) Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even though its 'late')
[ https://issues.apache.org/jira/browse/HBASE-15878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15878: -- Attachment: 15878.patch Patch I pushed to branch-1.1, branch-1.2, branch-1.3 and branch-1 deprecating doBulkLoad. > Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even > though its 'late') > > > Key: HBASE-15878 > URL: https://issues.apache.org/jira/browse/HBASE-15878 > Project: HBase > Issue Type: Sub-task >Reporter: stack > Fix For: 2.0.0 > > Attachments: 15878.patch > > > The parent issue is about our removing doBulkLoad(Path hfofDir, final HTable > table) in branch-2 even though it did not go through a proper deprecation > cycle. Here we are doing a backfill of deprecations (though it too late for > doBulkLoad(Path hfofDir, final HTable table) to enjoy a proper deprecation > cycle). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15878) Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even though its 'late')
stack created HBASE-15878: - Summary: Deprecate doBulkLoad(Path hfofDir, final HTable table) in branch-1 (even though its 'late') Key: HBASE-15878 URL: https://issues.apache.org/jira/browse/HBASE-15878 Project: HBase Issue Type: Sub-task Reporter: stack The parent issue is about our removing doBulkLoad(Path hfofDir, final HTable table) in branch-2 even though it did not go through a proper deprecation cycle. Here we are doing a backfill of deprecations (though it too late for doBulkLoad(Path hfofDir, final HTable table) to enjoy a proper deprecation cycle). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15806) An endpoint-based export tool
[ https://issues.apache.org/jira/browse/HBASE-15806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296424#comment-15296424 ] Ted Yu commented on HBASE-15806: Planning to commit later today if there is no more comment. > An endpoint-based export tool > - > > Key: HBASE-15806 > URL: https://issues.apache.org/jira/browse/HBASE-15806 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: ChiaPing Tsai >Assignee: ChiaPing Tsai >Priority: Minor > Fix For: 2.0.0 > > Attachments: Experiment.png, HBASE-15806.patch > > > The time for exporting table can be reduced, if we use the endpoint technique > to export the hdfs files by the region server rather than by hbase client. > In my experiments, the elapsed time of endpoint-based export can be less than > half of current export tool (enable the hdfs compression) > But the shortcomings is we need to alter table for deploying the endpoint > any comments about this? thanks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15873) ACL for snapshot restore / clone is not enforced
[
https://issues.apache.org/jira/browse/HBASE-15873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-15873:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
Thanks for the reviews.
> ACL for snapshot restore / clone is not enforced
>
>
> Key: HBASE-15873
> URL: https://issues.apache.org/jira/browse/HBASE-15873
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Fix For: 1.3.0, 1.4.0, 1.2.2, 1.1.6
>
> Attachments: HBASE-15873-branch-1.v1.txt
>
>
> [~romil.choksi] reported that snapshot owner couldn't restore snapshot on
> hbase 1.1
> We saw the following in master log:
> {code}
> 2016-05-20 00:22:17,186 DEBUG
> [B.defaultRpcServer.handler=23,queue=2,port=2] ipc.RpcServer:
> B.defaultRpcServer.handler=23,queue=2,port=2: callId: 15 service:
> MasterService methodName: RestoreSnapshot size: 70 connection: x.y:56508
> org.apache.hadoop.hbase.security.AccessDeniedException: Insufficient
> permissions for user 'hrt_1' (global, action=ADMIN)
> at
> org.apache.hadoop.hbase.security.access.AccessController.requireGlobalPermission(AccessController.java:536)
> at
> org.apache.hadoop.hbase.security.access.AccessController.requirePermission(AccessController.java:512)
> at
> org.apache.hadoop.hbase.security.access.AccessController.preRestoreSnapshot(AccessController.java:1327)
> at
> org.apache.hadoop.hbase.master.MasterCoprocessorHost$73.call(MasterCoprocessorHost.java:881)
> at
> org.apache.hadoop.hbase.master.MasterCoprocessorHost.execOperation(MasterCoprocessorHost.java:1146)
> at
> org.apache.hadoop.hbase.master.MasterCoprocessorHost.preRestoreSnapshot(MasterCoprocessorHost.java:877)
> at
> org.apache.hadoop.hbase.master.snapshot.SnapshotManager.restoreSnapshot(SnapshotManager.java:726)
> {code}
> After adding some debug information, it turned out that the (request)
> SnapshotDescription passed to the method doesn't have owner set.
> This problem doesn't exist in master branch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296314#comment-15296314
]
Jurriaan Mous commented on HBASE-15876:
---
The tests also fails for me locally on master and sometimes succeeds so seems
to be erratic. Can somebody confirm?
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296252#comment-15296252
]
Hadoop QA commented on HBASE-15876:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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
15s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
42s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 32s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
54s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 8m
27s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
10s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 100m 16s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 123m 58s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestRegionServerMetrics |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12805601/HBASE-15876.patch |
| JIRA Issue | HBASE-15876 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf907.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/test_framework/yetus-0.2.1/lib/precommit/personality/hbase.sh
|
| git revision | master / ae42c65 |
| Default Java | 1.7.0_79 |
| Multi-JDK versions |
[jira] [Updated] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jurriaan Mous updated HBASE-15876:
--
Attachment: HBASE-15876.patch
* Remove the mentioned doBulkLoad method
* Fix check style issues in touched classes
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jurriaan Mous updated HBASE-15876:
--
Status: Patch Available (was: Open)
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-15876.patch
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (HBASE-15876) Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been through a full deprecation cycle
[
https://issues.apache.org/jira/browse/HBASE-15876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jurriaan Mous reassigned HBASE-15876:
-
Assignee: Jurriaan Mous (was: stack)
> Remove doBulkLoad(Path hfofDir, final HTable table) though it has not been
> through a full deprecation cycle
> ---
>
> Key: HBASE-15876
> URL: https://issues.apache.org/jira/browse/HBASE-15876
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Jurriaan Mous
>Priority: Blocker
> Fix For: 2.0.0
>
>
> HBASE-15875 purges the properly deprecated HTable. The method doBulkLoad(Path
> hfofDir, final HTable table), while it has a deprecated param, the method
> itself did not get a deprecation label; it is a public method in a public
> class marked stable. This issue is about getting consensus that it is ok to
> remove this method used by offline tooling that will break until updated on
> upgrade to 2.0 w/o a proper deprecation cycle (I think it will be ok to do
> this -- the benefit of our being able to remove HTable is worth this minor
> inconvenience). We'll do some ugly patching of this oversight by adding a
> late deprecation and flagging the removal of this offline method as an
> incompatible change in 2.0. We'll add the deprecation in a subissue.
> It is a problem removing
> doBulkLoad(Path hfofDir, final HTable table)
> ... since this is a public/stable Class.
> There is the alternate:
> public void doBulkLoad(Path hfofDir, final Admin admin, Table table,
> RegionLocator regionLocator) throws TableNotFoundException, IOException
> {
> The former calls the latter.
> The latter went in here:
> {code}
> commit ac95cc1fbb951bb9db96f2738f621d1d7cd45739
> Author: tedyu
> Date: Fri Jan 2 19:48:06 2015 -0800
> HBASE-12783 Create efficient RegionLocator implementation (Solomon Duskis)
> {code}
> This was added in time for release 1.1.0.
> So, this method has not gone through a full major version of deprecation.
> It will break when someone moves to 2.0. But it is offline method. Not the
> end of the world.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-11819) Unit test for CoprocessorHConnection
[ https://issues.apache.org/jira/browse/HBASE-11819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Talat UYARER updated HBASE-11819: - Attachment: HBASE-11819v6-master.patch Updated for master. [~apurtell] Would you like to review ? > Unit test for CoprocessorHConnection > - > > Key: HBASE-11819 > URL: https://issues.apache.org/jira/browse/HBASE-11819 > Project: HBase > Issue Type: Test >Reporter: Andrew Purtell >Assignee: Talat UYARER >Priority: Minor > Labels: beginner > Fix For: 2.0.0, 0.98.14, 1.3.0, 1.2.2, 1.1.6 > > Attachments: HBASE-11819v4-master.patch, HBASE-11819v5-0.98 > (1).patch, HBASE-11819v5-0.98.patch, HBASE-11819v5-master (1).patch, > HBASE-11819v5-master.patch, HBASE-11819v5-master.patch, > HBASE-11819v5-v0.98.patch, HBASE-11819v5-v1.0.patch, > HBASE-11819v6-branch-1.patch, HBASE-11819v6-master.patch > > > Add a unit test to hbase-server that exercises CoprocessorHConnection . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15873) ACL for snapshot restore / clone is not enforced
[
https://issues.apache.org/jira/browse/HBASE-15873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296070#comment-15296070
]
Hudson commented on HBASE-15873:
SUCCESS: Integrated in HBase-1.1-JDK7 #1720 (See
[https://builds.apache.org/job/HBase-1.1-JDK7/1720/])
HBASE-15873 ACL for snapshot restore / clone is not enforced (tedyu: rev
0120d1dd401aab4d5df6852a33a9e5e856606be5)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/SnapshotManager.java
> ACL for snapshot restore / clone is not enforced
>
>
> Key: HBASE-15873
> URL: https://issues.apache.org/jira/browse/HBASE-15873
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Fix For: 1.3.0, 1.4.0, 1.2.2, 1.1.6
>
> Attachments: HBASE-15873-branch-1.v1.txt
>
>
> [~romil.choksi] reported that snapshot owner couldn't restore snapshot on
> hbase 1.1
> We saw the following in master log:
> {code}
> 2016-05-20 00:22:17,186 DEBUG
> [B.defaultRpcServer.handler=23,queue=2,port=2] ipc.RpcServer:
> B.defaultRpcServer.handler=23,queue=2,port=2: callId: 15 service:
> MasterService methodName: RestoreSnapshot size: 70 connection: x.y:56508
> org.apache.hadoop.hbase.security.AccessDeniedException: Insufficient
> permissions for user 'hrt_1' (global, action=ADMIN)
> at
> org.apache.hadoop.hbase.security.access.AccessController.requireGlobalPermission(AccessController.java:536)
> at
> org.apache.hadoop.hbase.security.access.AccessController.requirePermission(AccessController.java:512)
> at
> org.apache.hadoop.hbase.security.access.AccessController.preRestoreSnapshot(AccessController.java:1327)
> at
> org.apache.hadoop.hbase.master.MasterCoprocessorHost$73.call(MasterCoprocessorHost.java:881)
> at
> org.apache.hadoop.hbase.master.MasterCoprocessorHost.execOperation(MasterCoprocessorHost.java:1146)
> at
> org.apache.hadoop.hbase.master.MasterCoprocessorHost.preRestoreSnapshot(MasterCoprocessorHost.java:877)
> at
> org.apache.hadoop.hbase.master.snapshot.SnapshotManager.restoreSnapshot(SnapshotManager.java:726)
> {code}
> After adding some debug information, it turned out that the (request)
> SnapshotDescription passed to the method doesn't have owner set.
> This problem doesn't exist in master branch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
