[jira] [Commented] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[
https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222715#comment-15222715
]
Hadoop QA commented on HBASE-15577:
---
| (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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 39s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 9m
1s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m 23s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 18s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
59s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
12s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
54s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 36s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 7s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 15s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
57s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 28s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 28s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 56s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 56s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
6s {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 5 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
36m 9s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
22s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 19s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 49s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 24s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 22s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 17s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 17s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
42s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 111m 25s {color}
| {color:black}
[jira] [Updated] (HBASE-15582) SnapshotManifestV1 too verbose when there are no regions
[ https://issues.apache.org/jira/browse/HBASE-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-15582: Resolution: Fixed Fix Version/s: 1.1.5 0.98.19 1.0.4 1.2.1 1.3.0 2.0.0 Status: Resolved (was: Patch Available) > SnapshotManifestV1 too verbose when there are no regions > > > Key: HBASE-15582 > URL: https://issues.apache.org/jira/browse/HBASE-15582 > Project: HBase > Issue Type: Bug > Components: master, snapshots >Affects Versions: 2.0.0, 1.2.0, 1.3.0, 1.1.4, 0.98.16.1 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Trivial > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.0.4, 0.98.19, 1.1.5 > > Attachments: HBASE-15582-v0.patch > > > swap the INFO for DEBUG in SnapshotManifestV1.loadRegionManifests() otherwise > the cleaner will spam everyone for no reason -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15580) Tag coprocessor limitedprivate scope to StoreFile.Reader
[
https://issues.apache.org/jira/browse/HBASE-15580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajeshbabu Chintaguntla updated HBASE-15580:
Fix Version/s: 1.0.4
Status: Patch Available (was: Open)
> Tag coprocessor limitedprivate scope to StoreFile.Reader
>
>
> Key: HBASE-15580
> URL: https://issues.apache.org/jira/browse/HBASE-15580
> Project: HBase
> Issue Type: Improvement
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
> Fix For: 2.0.0, 1.0.4, 0.98.19, 1.1.5, 1.2.2
>
> Attachments: HBASE-15580.patch, HBASE-15580_branch-1.0.patch
>
>
> For phoenix local indexing we need to have custom storefile reader
> constructor(IndexHalfStoreFileReader) to distinguish from other storefile
> readers. So wanted to mark StoreFile.Reader scope as
> InterfaceAudience.LimitedPrivate("Coprocessor")
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15580) Tag coprocessor limitedprivate scope to StoreFile.Reader
[
https://issues.apache.org/jira/browse/HBASE-15580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajeshbabu Chintaguntla updated HBASE-15580:
Attachment: HBASE-15580_branch-1.0.patch
This patch can be applied for branch-1.0 and 0.98
> Tag coprocessor limitedprivate scope to StoreFile.Reader
>
>
> Key: HBASE-15580
> URL: https://issues.apache.org/jira/browse/HBASE-15580
> Project: HBase
> Issue Type: Improvement
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
> Fix For: 2.0.0, 1.0.4, 0.98.19, 1.1.5, 1.2.2
>
> Attachments: HBASE-15580.patch, HBASE-15580_branch-1.0.patch
>
>
> For phoenix local indexing we need to have custom storefile reader
> constructor(IndexHalfStoreFileReader) to distinguish from other storefile
> readers. So wanted to mark StoreFile.Reader scope as
> InterfaceAudience.LimitedPrivate("Coprocessor")
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15580) Tag coprocessor limitedprivate scope to StoreFile.Reader
[
https://issues.apache.org/jira/browse/HBASE-15580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajeshbabu Chintaguntla updated HBASE-15580:
Attachment: HBASE-15580.patch
[~apurtell] Here is the patch can be applied for master, branch-1.2, branch-1.1
> Tag coprocessor limitedprivate scope to StoreFile.Reader
>
>
> Key: HBASE-15580
> URL: https://issues.apache.org/jira/browse/HBASE-15580
> Project: HBase
> Issue Type: Improvement
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
> Fix For: 2.0.0, 0.98.19, 1.1.5, 1.2.2
>
> Attachments: HBASE-15580.patch
>
>
> For phoenix local indexing we need to have custom storefile reader
> constructor(IndexHalfStoreFileReader) to distinguish from other storefile
> readers. So wanted to mark StoreFile.Reader scope as
> InterfaceAudience.LimitedPrivate("Coprocessor")
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-15588) Use nonce for checkAndMutate operation
Jianwei Cui created HBASE-15588:
---
Summary: Use nonce for checkAndMutate operation
Key: HBASE-15588
URL: https://issues.apache.org/jira/browse/HBASE-15588
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 2.0.0
Reporter: Jianwei Cui
Like {{increment}}/{{append}}, the {{checkAndPut}}/{{checkAndDelete}} operation
is non-idempotent, so that the client may get incorrect result if there are
retries, and such incorrect result may lead the application enter an error
state. A possible solution is using nonce for checkAndMutate operations,
discussions and suggestions are welcomed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15587) FSTableDescriptors.getDescriptor() logs stack trace erronously
[
https://issues.apache.org/jira/browse/HBASE-15587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222681#comment-15222681
]
Hadoop QA commented on HBASE-15587:
---
| (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
51s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 1s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 45s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
1s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
34s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 43s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 47s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
59s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 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 45s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 45s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
19s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s {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}
35m 30s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
59s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 43s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 50s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 127m 6s {color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
22s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 192m 31s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient |
| |
org.apache.hadoop.hbase.client.replication.TestReplicationAdminWithClusters |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12796627/hbase-15587-v1.patch |
| JIRA Issue | HBASE-15587 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux pomona.apache.org 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/component/dev-support/hbase-personality.sh
[jira] [Resolved] (HBASE-15404) PE: Clients in append and increment are operating serially
[
https://issues.apache.org/jira/browse/HBASE-15404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Appy resolved HBASE-15404.
--
Resolution: Invalid
Clients are still working parallely, except that they all process keys from a
same small range at a time. for eg. fist 0 - 1M, then 1M - 2M, so on..
Thanks stack for explaining.
> PE: Clients in append and increment are operating serially
> --
>
> Key: HBASE-15404
> URL: https://issues.apache.org/jira/browse/HBASE-15404
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Affects Versions: 1.2.0
>Reporter: Appy
>
> On running hbase pe --nomapred increment/append 10, i see the following
> output where it seems like threads are executing operations serially. In the
> UI too, only one RS is getting requests at a time.
> {noformat}
> 6/03/05 22:26:15 INFO hbase.PerformanceEvaluation: Timed test starting in
> thread TestClient-1
> 16/03/05 22:26:15 INFO hbase.PerformanceEvaluation: Timed test starting in
> thread TestClient-2
> 16/03/05 22:26:15 INFO hbase.PerformanceEvaluation: Timed test starting in
> thread TestClient-8
> 16/03/05 22:26:15 INFO hbase.PerformanceEvaluation: Timed test starting in
> thread TestClient-0
> 16/03/05 22:26:15 INFO hbase.PerformanceEvaluation: Timed test starting in
> thread TestClient-4
> 16/03/05 22:26:15 INFO hbase.PerformanceEvaluation: Timed test starting in
> thread TestClient-6
> 16/03/05 22:26:15 INFO hbase.PerformanceEvaluation: Timed test starting in
> thread TestClient-7
> 16/03/05 22:26:15 INFO hbase.PerformanceEvaluation: Timed test starting in
> thread TestClient-5
> 16/03/05 22:26:15 INFO hbase.PerformanceEvaluation: Timed test starting in
> thread TestClient-9
> 16/03/05 22:26:15 INFO hbase.PerformanceEvaluation: Timed test starting in
> thread TestClient-3
> 16/03/05 22:27:54 INFO hbase.PerformanceEvaluation: 0/104857/1048576, latency
> mean=942.48, min=390.00, max=163444.00, stdDev=892.64, 95th=1361.00,
> 99th=1605.00
> 16/03/05 22:27:54 INFO hbase.PerformanceEvaluation: 0/104857/1048576, latency
> mean=942.53, min=366.00, max=163400.00, stdDev=885.49, 95th=1361.00,
> 99th=1605.00
> 16/03/05 22:27:54 INFO hbase.PerformanceEvaluation: 0/104857/1048576, latency
> mean=942.41, min=402.00, max=163436.00, stdDev=891.54, 95th=1359.00,
> 99th=1602.41
> 16/03/05 22:27:54 INFO hbase.PerformanceEvaluation: 0/104857/1048576, latency
> mean=942.51, min=399.00, max=163610.00, stdDev=892.40, 95th=1360.00,
> 99th=1600.00
> 16/03/05 22:27:54 INFO hbase.PerformanceEvaluation: 0/104857/1048576, latency
> mean=942.59, min=393.00, max=162932.00, stdDev=887.65, 95th=1361.00,
> 99th=1604.00
> 16/03/05 22:27:54 INFO hbase.PerformanceEvaluation: 0/104857/1048576, latency
> mean=942.26, min=385.00, max=163482.00, stdDev=891.71, 95th=1358.00,
> 99th=1599.00
> 16/03/05 22:27:54 INFO hbase.PerformanceEvaluation: 0/104857/1048576, latency
> mean=942.51, min=383.00, max=163246.00, stdDev=888.07, 95th=1360.00,
> 99th=1605.00
> 16/03/05 22:27:54 INFO hbase.PerformanceEvaluation: 0/104857/1048576, latency
> mean=942.45, min=385.00, max=163405.00, stdDev=886.65, 95th=1359.00,
> 99th=1604.00
> 16/03/05 22:27:54 INFO hbase.PerformanceEvaluation: 0/104857/1048576, latency
> mean=942.38, min=400.00, max=163580.00, stdDev=887.28, 95th=1359.00,
> 99th=1602.00
> 16/03/05 22:27:54 INFO hbase.PerformanceEvaluation: 0/104857/1048576, latency
> mean=942.29, min=407.00, max=163403.00, stdDev=889.77, 95th=1357.00,
> 99th=1597.00
> 16/03/05 22:29:35 INFO hbase.PerformanceEvaluation: 0/209714/1048576, latency
> mean=950.75, min=366.00, max=163400.00, stdDev=817.84, 95th=1363.00,
> 99th=1605.00
> 16/03/05 22:29:35 INFO hbase.PerformanceEvaluation: 0/209714/1048576, latency
> mean=950.75, min=383.00, max=163246.00, stdDev=821.95, 95th=1363.00,
> 99th=1604.00
> 16/03/05 22:29:35 INFO hbase.PerformanceEvaluation: 0/209714/1048576, latency
> mean=950.75, min=389.00, max=163444.00, stdDev=824.03, 95th=1364.00,
> 99th=1603.00
> 16/03/05 22:29:35 INFO hbase.PerformanceEvaluation: 0/209714/1048576, latency
> mean=950.56, min=382.00, max=163403.00, stdDev=822.44, 95th=1363.00,
> 99th=1603.00
> 16/03/05 22:29:35 INFO hbase.PerformanceEvaluation: 0/209714/1048576, latency
> mean=950.79, min=393.00, max=162932.00, stdDev=818.75, 95th=1365.00,
> 99th=1601.84
> 16/03/05 22:29:35 INFO hbase.PerformanceEvaluation: 0/209714/1048576, latency
> mean=950.70, min=388.00, max=163436.00, stdDev=823.52, 95th=1364.00,
> 99th=1606.00
> 16/03/05 22:29:35 INFO hbase.PerformanceEvaluation: 0/209714/1048576, latency
> mean=950.72, min=376.00, max=163405.00, stdDev=820.65, 95th=1364.00,
> 99th=1605.00
> 16/03/05 22:29:35 INFO hbase.PerformanceEvaluation: 0/209714/1048576, latency
> mean=950.56, min=382.00, max=163482.00, stdDev=823.43, 95th=1363.00,
[jira] [Updated] (HBASE-15577) there need be a mechanism to enable ZK's ACL check when the authentication strategy is simple
[ https://issues.apache.org/jira/browse/HBASE-15577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu updated HBASE-15577: --- Attachment: HBASE-15577.patch patch for the master > there need be a mechanism to enable ZK's ACL check when the authentication > strategy is simple > - > > Key: HBASE-15577 > URL: https://issues.apache.org/jira/browse/HBASE-15577 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.1.3 >Reporter: chenxu >Assignee: chenxu > Attachments: HBASE-15577.patch, zk-set-acl.patch > > > if the hbase.security.authentication is set to simple, the ZKUtil.createACL > just return Ids.OPEN_ACL_UNSAFE, means that there is no ACL check on the ZK's > node. > we can refactoring this to enables the ACL's check function -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15586) Unify human readable numbers in the web UI
[
https://issues.apache.org/jira/browse/HBASE-15586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222660#comment-15222660
]
Hadoop QA commented on HBASE-15586:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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
25s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 38s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 37s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
49s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
19s {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 12 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
32m 21s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 42s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 41s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 142m 31s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 182m 53s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.master.procedure.TestMasterFailoverWithProcedures |
| Timed out junit tests |
org.apache.hadoop.hbase.security.access.TestNamespaceCommands |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12796623/hbase-15586-v1.patch |
| JIRA Issue | HBASE-15586 |
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux asf910.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/component/dev-support/hbase-personality.sh
|
| git revision | master / 25419d8 |
| 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 |
| whitespace |
https://builds.apache.org/job/PreCommit-HBASE-Build/1272/artifact/patchprocess/whitespace-eol.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/1272/artifact/patchprocess/patch-unit-hbase-server.txt
|
| unit test logs |
https://builds.apache.org/job/PreCommit-HBASE-Build/1272/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/1272/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/1272/console |
| Powered by | Apache Yetus 0.2.0 http://yetus.apache.org |
This message was automatically generated.
> Unify human readable numbers in the web UI
> ---
>
> Key: HBASE-15586
> URL: https://issues.apache.org/jira/browse/HBASE-15586
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: Screen Shot 2016-04-01 at 3.52.00 PM.png, Screen Shot
> 2016-04-01 at 3.52.12 PM.png, Screen Shot 2016-04-01 at 3.52.32 PM.png,
> Screen Shot 2016-04-01 at 3.52.38 PM.png, Screen Shot 2016-04-01 at 3.52.49
> PM.png, hbase-15586-v1.patch, hbase-15586-v1.patch
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222658#comment-15222658 ] Dave Latham commented on HBASE-15585: - Andrew, I apologize for the poor attempt at humor. I've always given an incredulous laugh at the criticism of HBase coprocessors by some folks. For the record I think the way they are built makes a lot of sense and greatly appreciate all you've done for HBase. Poe's law strikes again. > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.01.patch, HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15581) Reduce garbage created by PB in write path
[ https://issues.apache.org/jira/browse/HBASE-15581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222656#comment-15222656 ] Anoop Sam John commented on HBASE-15581: +1.. Which is that Jira Elliot? I can take that up first or request some one help :-) > Reduce garbage created by PB in write path > -- > > Key: HBASE-15581 > URL: https://issues.apache.org/jira/browse/HBASE-15581 > Project: HBase > Issue Type: Sub-task >Reporter: Anoop Sam John >Assignee: Anoop Sam John > > Changes such that PB code will not make much garbage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15581) Reduce garbage created by PB in write path
[ https://issues.apache.org/jira/browse/HBASE-15581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222646#comment-15222646 ] Elliott Clark commented on HBASE-15581: --- We need to get all the PB out of api's before we can move to a shaded 2.6. > Reduce garbage created by PB in write path > -- > > Key: HBASE-15581 > URL: https://issues.apache.org/jira/browse/HBASE-15581 > Project: HBase > Issue Type: Sub-task >Reporter: Anoop Sam John >Assignee: Anoop Sam John > > Changes such that PB code will not make much garbage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15581) Reduce garbage created by PB in write path
[ https://issues.apache.org/jira/browse/HBASE-15581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222644#comment-15222644 ] Anoop Sam John commented on HBASE-15581: Ya at least move to 2.6.0.. When/if we need PB to work with DBB, we will add this work on top of 2.6 base. Ya shading might be better choice.. Will see this part. > Reduce garbage created by PB in write path > -- > > Key: HBASE-15581 > URL: https://issues.apache.org/jira/browse/HBASE-15581 > Project: HBase > Issue Type: Sub-task >Reporter: Anoop Sam John >Assignee: Anoop Sam John > > Changes such that PB code will not make much garbage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15583) Discuss mutable vs immutable HTableDescriptor
[ https://issues.apache.org/jira/browse/HBASE-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15583: -- Labels: beginner (was: ) > Discuss mutable vs immutable HTableDescriptor > - > > Key: HBASE-15583 > URL: https://issues.apache.org/jira/browse/HBASE-15583 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Gabor Liptak >Priority: Minor > Labels: beginner > Fix For: 2.0.0 > > > From [~enis] in https://issues.apache.org/jira/browse/HBASE-15505: > PS Should UnmodifyableHTableDescriptor be renamed to > UnmodifiableHTableDescriptor? > It should be named ImmutableHTableDescriptor to be consistent with > collections naming. Let's do this as a subtask of the parent jira, not here. > Thinking about it though, why would we return an Immutable HTD in > HTable.getTableDescriptor() versus a mutable HTD in > Admin.getTableDescriptor(). It does not make sense. Should we just get rid of > the Immutable ones? > We also have UnmodifyableHRegionInfo which is not used at the moment it > seems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15583) Discuss mutable vs immutable HTableDescriptor
[ https://issues.apache.org/jira/browse/HBASE-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222626#comment-15222626 ] Enis Soztutar commented on HBASE-15583: --- I would say, just get rid of the immutable ones. They are not used. > Discuss mutable vs immutable HTableDescriptor > - > > Key: HBASE-15583 > URL: https://issues.apache.org/jira/browse/HBASE-15583 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Gabor Liptak >Priority: Minor > Labels: beginner > Fix For: 2.0.0 > > > From [~enis] in https://issues.apache.org/jira/browse/HBASE-15505: > PS Should UnmodifyableHTableDescriptor be renamed to > UnmodifiableHTableDescriptor? > It should be named ImmutableHTableDescriptor to be consistent with > collections naming. Let's do this as a subtask of the parent jira, not here. > Thinking about it though, why would we return an Immutable HTD in > HTable.getTableDescriptor() versus a mutable HTD in > Admin.getTableDescriptor(). It does not make sense. Should we just get rid of > the Immutable ones? > We also have UnmodifyableHRegionInfo which is not used at the moment it > seems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14870) Backport namespace permissions to 98 branch
[
https://issues.apache.org/jira/browse/HBASE-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222621#comment-15222621
]
Hadoop QA commented on HBASE-14870:
---
| (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 3 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 2m 1s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
26s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 24s
{color} | {color:green} 0.98 passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 13s
{color} | {color:green} 0.98 passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
58s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
43s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m
50s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 45s
{color} | {color:red} hbase-server in 0.98 has 82 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 1m 19s
{color} | {color:red} hbase-server in 0.98 failed with JDK v1.8.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 4s
{color} | {color:green} 0.98 passed with JDK v1.7.0_79 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 14s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
48s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 48s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 4m 48s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m 48s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 25s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 2m 25s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 25s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
54s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
2s {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 136 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
14m 57s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 1m
37s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 11m
59s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 1m 19s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0. {color}
|
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 1m 17s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0. {color}
|
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 8m 49s
{color} | {color:red} hbase-server-jdk1.7.0_79 with JDK v1.7.0_79 generated 24
new + 24 unchanged - 0 fixed = 48 total (was 24) {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 8m 49s
{color} | {color:red} hbase-server-jdk1.7.0_79 with JDK v1.7.0_79 generated 24
new + 24 unchanged - 0 fixed = 48
[jira] [Commented] (HBASE-15572) Adding optional timestamp semantics to HBase-Spark
[
https://issues.apache.org/jira/browse/HBASE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222620#comment-15222620
]
Hadoop QA commented on HBASE-15572:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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 10s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
0s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m 46s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m 54s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
3s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 49s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 11s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} scaladoc {color} | {color:red} 0m 7s
{color} | {color:red} root in master failed. {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} 7m
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m 55s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 5m 55s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} scalac {color} | {color:green} 5m 55s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m 57s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m 57s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} scalac {color} | {color:green} 6m 57s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
5s {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}
26m 6s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 49s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 14s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} scaladoc {color} | {color:red} 0m 6s
{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} scaladoc {color} | {color:red} 0m 6s
{color} | {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 9s
{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 11s
{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 9s
{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 17s
{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 107m 24s
{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
8s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 200m 27s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222614#comment-15222614 ] Sergey Shelukhin commented on HBASE-15585: -- Well, at least it was a pretty innocent joke... I am sorry to have offended anyone. I found the coprocessor nuclear-bomb capabilities funny when refactoring compaction code ages ago (e.g. the ones mentioned in JIRA description), but missed the previous AF days > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.01.patch, HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-15585: - Resolution: Won't Fix Status: Resolved (was: Patch Available) > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.01.patch, HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15187) Integrate CSRF prevention filter to REST gateway
[ https://issues.apache.org/jira/browse/HBASE-15187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222590#comment-15222590 ] Ted Yu commented on HBASE-15187: TestMasterFailoverWithProcedures is flaky - I have seen it in other QA runs. > Integrate CSRF prevention filter to REST gateway > > > Key: HBASE-15187 > URL: https://issues.apache.org/jira/browse/HBASE-15187 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0 > > Attachments: HBASE-15187-branch-1.v13.patch, HBASE-15187.v1.patch, > HBASE-15187.v10.patch, HBASE-15187.v10.patch, HBASE-15187.v11.patch, > HBASE-15187.v12.patch, HBASE-15187.v13.patch, HBASE-15187.v2.patch, > HBASE-15187.v3.patch, HBASE-15187.v4.patch, HBASE-15187.v5.patch, > HBASE-15187.v6.patch, HBASE-15187.v7.patch, HBASE-15187.v8.patch, > HBASE-15187.v9.patch > > > HADOOP-12691 introduced a filter in Hadoop Common to help REST APIs guard > against cross-site request forgery attacks. > This issue tracks the integration of that filter into HBase REST gateway. > From REST section of refguide: > To delete a table, use a DELETE request with the /schema endpoint: > http://example.com:8000/schema > Suppose an attacker hosts a malicious web form on a domain under his control. > The form uses the DELETE action targeting a REST URL. Through social > engineering, the attacker tricks an authenticated user into accessing the > form and submitting it. > The browser sends the HTTP DELETE request to the REST gateway. > At REST gateway, the call is executed and user table is dropped -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222582#comment-15222582 ] Sean Busbey commented on HBASE-15585: - I am only sorry that I have only 1 like to give to Andrew's evaluation. > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.01.patch, HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15187) Integrate CSRF prevention filter to REST gateway
[
https://issues.apache.org/jira/browse/HBASE-15187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222575#comment-15222575
]
Hadoop QA commented on HBASE-15187:
---
| (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 3 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 22s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 4s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 40s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
27s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
49s {color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s
{color} | {color:blue} Skipped branch modules with no Java source: . {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 42s
{color} | {color:red} hbase-rest in master has 2 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 41s
{color} | {color:red} hbase-rest in master has 2 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m 7s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 26s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 8s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
55s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m 4s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m 4s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m 27s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m 27s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
30s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
48s {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 6 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 0s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
26m 4s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s
{color} | {color:blue} Skipped patch modules with no Java source: . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
58s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m 9s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 28s
{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} 1m 44s
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} |
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[
https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222568#comment-15222568
]
Hadoop QA commented on HBASE-15585:
---
| (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} 4m
25s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 6s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
27s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
37s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 45s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 49s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 34s
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 43s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0. {color}
|
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 43s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 33s
{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_79.
{color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 33s {color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_79. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 5m 29s
{color} | {color:red} hbase-server: patch generated 8 new + 123 unchanged - 1
fixed = 131 total (was 124) {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
21s {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 1 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 1s
{color} | {color:red} The patch has 10 line(s) with tabs. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m 13s
{color} | {color:red} Patch causes 14 errors with Hadoop v2.4.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m 20s
{color} | {color:red} Patch causes 14 errors with Hadoop v2.4.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m 28s
{color} | {color:red} Patch causes 14 errors with Hadoop v2.5.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 4m 35s
{color} | {color:red} Patch causes 14 errors with Hadoop v2.5.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m 44s
{color} | {color:red} Patch causes 14 errors with Hadoop v2.5.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m 50s
{color} | {color:red} Patch causes 14 errors with Hadoop v2.6.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 7m 58s
{color} | {color:red} Patch causes 14 errors with Hadoop v2.6.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 9m 7s
{color} | {color:red} Patch causes 14 errors with Hadoop v2.6.3. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 10m 16s
{color} | {color:red} Patch causes 14 errors with Hadoop v2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 28s
{color} | {color:red} hbase-server in the
[jira] [Updated] (HBASE-15587) FSTableDescriptors.getDescriptor() logs stack trace erronously
[ https://issues.apache.org/jira/browse/HBASE-15587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15587: -- Status: Patch Available (was: Open) > FSTableDescriptors.getDescriptor() logs stack trace erronously > -- > > Key: HBASE-15587 > URL: https://issues.apache.org/jira/browse/HBASE-15587 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: hbase-15587-v1.patch > > > Long time pet-peeve, but it is causing some confusion when looking at the > master logs for unrelated things. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15587) FSTableDescriptors.getDescriptor() logs stack trace erronously
[ https://issues.apache.org/jira/browse/HBASE-15587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15587: -- Attachment: hbase-15587-v1.patch Simple patch. > FSTableDescriptors.getDescriptor() logs stack trace erronously > -- > > Key: HBASE-15587 > URL: https://issues.apache.org/jira/browse/HBASE-15587 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: hbase-15587-v1.patch > > > Long time pet-peeve, but it is causing some confusion when looking at the > master logs for unrelated things. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15587) FSTableDescriptors.getDescriptor() logs stack trace erronously
Enis Soztutar created HBASE-15587: - Summary: FSTableDescriptors.getDescriptor() logs stack trace erronously Key: HBASE-15587 URL: https://issues.apache.org/jira/browse/HBASE-15587 Project: HBase Issue Type: Bug Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 2.0.0, 1.3.0, 1.4.0 Long time pet-peeve, but it is causing some confusion when looking at the master logs for unrelated things. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222562#comment-15222562 ] Andrew Purtell commented on HBASE-15585: And I'm sorry but if this is an April fools joke it's not the least bit funny. > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.01.patch, HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222559#comment-15222559 ] Andrew Purtell commented on HBASE-15585: As for "please reimplement"... Your patch for HBASE-4047 is welcome anytime (smile) > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.01.patch, HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222557#comment-15222557 ] Andrew Purtell commented on HBASE-15585: Coprocessors aren't meant as a means to run arbitrary unvetted user code [~davelatham] and never have been. They are exactly meant to extend HBase in the same JVM for maximum performance and flexibility - for the HBase developers. As you say something external would be appropriate for hosting random user code you want to run server side. > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.01.patch, HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-10346) Add Documentation for stateless scanner
[ https://issues.apache.org/jira/browse/HBASE-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222545#comment-15222545 ] Duo Xu commented on HBASE-10346: [~avandana] I am trying to deserialize the protobuf response when using stateless scanner curl -H "Accept: application/x-protobuf" http://10.0.0.4:8090/testtable/* I am using CellSet generated from CellSetMessage.proto, but it cannot decode the reponse stream. CellSet works fine in stateful scanner though. Am I using the right proto generated class or this is a bug in stateless scanner? Thanks, Duo > Add Documentation for stateless scanner > --- > > Key: HBASE-10346 > URL: https://issues.apache.org/jira/browse/HBASE-10346 > Project: HBase > Issue Type: Improvement > Components: REST >Reporter: Vandana Ayyalasomayajula >Assignee: Vandana Ayyalasomayajula >Priority: Minor > Fix For: 0.98.0, 0.99.0 > > Attachments: HBASE-10346.0.patch, HBASE-10346.1.patch, > HBASE-10346.addendum.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222542#comment-15222542 ] Dave Latham commented on HBASE-15585: - Coprocessors should never have run inside the same JVM. What happens if an untrusted version of this coprocessor should run? Please reimplement as a new framework in a separate process with a harness to communicate to the RS securely. > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.01.patch, HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[
https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222535#comment-15222535
]
Enis Soztutar commented on HBASE-15585:
---
{code}
diff --git
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/RegionServerObserver.java
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/RegionServerObserver.java
{code}
We should do the same for {{MasterObserver}} as well. Not being able to
override master and regionserver together will not result in ultimate
flexibility. -1 until that is addressed.
> RegionServer coprocessors are not flexible enough
> -
>
> Key: HBASE-15585
> URL: https://issues.apache.org/jira/browse/HBASE-15585
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors, regionserver
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
> Attachments: HBASE-15585.01.patch, HBASE-15585.patch
>
>
> While you can do all kinds of things with coprocessors, like arbitrarily
> discard memstore data or replace files randomly during compaction, I believe
> the ultimate power and flexibility is not there. The patch aims to address
> this shortcoming.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15572) Adding optional timestamp semantics to HBase-Spark
[ https://issues.apache.org/jira/browse/HBASE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222530#comment-15222530 ] Weiqing Yang commented on HBASE-15572: -- [~busbey] The v5 is updated (spark.adoc). Thanks. > Adding optional timestamp semantics to HBase-Spark > -- > > Key: HBASE-15572 > URL: https://issues.apache.org/jira/browse/HBASE-15572 > Project: HBase > Issue Type: New Feature > Components: spark >Reporter: Weiqing Yang >Assignee: Weiqing Yang > Fix For: 2.0.0 > > Attachments: HBASE-15572-1.patch, HBASE-15572-2.patch, > HBASE-15572-3.patch, HBASE-15572-4.patch, HBASE-15572-5.patch > > > Right now the timestamp is always latest. With this patch, users can select > timestamps they want. > In this patch, 4 parameters, "timestamp", "minTimestamp", "maxiTimestamp" and > "maxVersions" are added to HBaseSparkConf. Users can select a timestamp, they > can also select a time range with minimum timestamp and maximum timestamp. A > new test for selecting records with different timestamps is added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222516#comment-15222516 ] Dima Spivak commented on HBASE-15585: - -1. The spaces in the definition of CoprocessorNopeException don't conform to the Apache style guide. > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.01.patch, HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-15585: - Attachment: HBASE-15585.01.patch Updated the patch. I wouldn't be able to provide a specific use case right now, but it's in the same vein as many other coprocessors. Sometimes, a complex business use-case just cannot be implemented with standard HBase features, flexible as they are. Who are we to decide that overriding some core logic in a radical way to allow for such implementation is not the right answer? > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.01.patch, HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15505) ReplicationPeerConfig should be builder-style
[
https://issues.apache.org/jira/browse/HBASE-15505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222507#comment-15222507
]
Gabor Liptak commented on HBASE-15505:
--
Removed TestAppend (it was already covered) and corrected unit test.
> ReplicationPeerConfig should be builder-style
> -
>
> Key: HBASE-15505
> URL: https://issues.apache.org/jira/browse/HBASE-15505
> Project: HBase
> Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Gabor Liptak
> Labels: beginner, beginners
> Fix For: 2.0.0
>
> Attachments: HBASE-15505.1.patch, HBASE-15505.2.patch,
> HBASE-15505.3.patch, HBASE-15505.4.patch
>
>
> Similar to HTD, HCD, {{ReplicationPeerConfig}} should be builder-style:
> {code}
> ReplicationPeerConfig().setFoo(foo).setBar(bar);
> {code}
> See {{TestHTableDescriptor.testClassMethodsAreBuilderStyle()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[
https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222497#comment-15222497
]
Sean Busbey commented on HBASE-15585:
-
{code}
+ public boolean preStart() throws IOException {
{code}
please include a javadoc
> RegionServer coprocessors are not flexible enough
> -
>
> Key: HBASE-15585
> URL: https://issues.apache.org/jira/browse/HBASE-15585
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors, regionserver
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
> Attachments: HBASE-15585.patch
>
>
> While you can do all kinds of things with coprocessors, like arbitrarily
> discard memstore data or replace files randomly during compaction, I believe
> the ultimate power and flexibility is not there. The patch aims to address
> this shortcoming.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[
https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222495#comment-15222495
]
Sean Busbey commented on HBASE-15585:
-
{code}
+ if (this.rsHost != null) {
+boolean shouldWeEvenBother = rsHost.preStart();
+if (!shouldWeEvenBother) {
{code}
Either make the variable final or elide the call directly into the if check
> RegionServer coprocessors are not flexible enough
> -
>
> Key: HBASE-15585
> URL: https://issues.apache.org/jira/browse/HBASE-15585
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors, regionserver
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
> Attachments: HBASE-15585.patch
>
>
> While you can do all kinds of things with coprocessors, like arbitrarily
> discard memstore data or replace files randomly during compaction, I believe
> the ultimate power and flexibility is not there. The patch aims to address
> this shortcoming.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[
https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222493#comment-15222493
]
Sean Busbey commented on HBASE-15585:
-
{code}
- private static final Log LOG = LogFactory.getLog(HRegionServer.class);
+ public class CoprocessorNopeException extends CoprocessorException {
+private static final long serialVersionUID = 0x1339F91;
+public CoprocessorNopeException() {
+ super("Nope.");
+}
+ }
+
+private static final Log LOG = LogFactory.getLog(HRegionServer.class);
{code}
please do not change the formatting of hte LOG member unnecessarily.
> RegionServer coprocessors are not flexible enough
> -
>
> Key: HBASE-15585
> URL: https://issues.apache.org/jira/browse/HBASE-15585
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors, regionserver
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
> Attachments: HBASE-15585.patch
>
>
> While you can do all kinds of things with coprocessors, like arbitrarily
> discard memstore data or replace files randomly during compaction, I believe
> the ultimate power and flexibility is not there. The patch aims to address
> this shortcoming.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-15585: Component/s: regionserver Coprocessors > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222490#comment-15222490 ] Sean Busbey commented on HBASE-15585: - -1 please include a use case. > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15586) Unify human readable numbers in the web UI
[ https://issues.apache.org/jira/browse/HBASE-15586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15586: -- Status: Patch Available (was: Open) > Unify human readable numbers in the web UI > --- > > Key: HBASE-15586 > URL: https://issues.apache.org/jira/browse/HBASE-15586 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: Screen Shot 2016-04-01 at 3.52.00 PM.png, Screen Shot > 2016-04-01 at 3.52.12 PM.png, Screen Shot 2016-04-01 at 3.52.32 PM.png, > Screen Shot 2016-04-01 at 3.52.38 PM.png, Screen Shot 2016-04-01 at 3.52.49 > PM.png, hbase-15586-v1.patch, hbase-15586-v1.patch > > > I was looking at something else in the regionserver web ui trying to > understand the WAL size, and we are reporting that as raw bytes, not in MB / > GB range. Did a quick sweep to unify all the human-readable representations > in the UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15586) Unify human readable numbers in the web UI
[ https://issues.apache.org/jira/browse/HBASE-15586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15586: -- Attachment: hbase-15586-v1.patch > Unify human readable numbers in the web UI > --- > > Key: HBASE-15586 > URL: https://issues.apache.org/jira/browse/HBASE-15586 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: Screen Shot 2016-04-01 at 3.52.00 PM.png, Screen Shot > 2016-04-01 at 3.52.12 PM.png, Screen Shot 2016-04-01 at 3.52.32 PM.png, > Screen Shot 2016-04-01 at 3.52.38 PM.png, Screen Shot 2016-04-01 at 3.52.49 > PM.png, hbase-15586-v1.patch, hbase-15586-v1.patch > > > I was looking at something else in the regionserver web ui trying to > understand the WAL size, and we are reporting that as raw bytes, not in MB / > GB range. Did a quick sweep to unify all the human-readable representations > in the UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15586) Unify human readable numbers in the web UI
[ https://issues.apache.org/jira/browse/HBASE-15586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15586: -- Attachment: Screen Shot 2016-04-01 at 3.52.49 PM.png Screen Shot 2016-04-01 at 3.52.38 PM.png Screen Shot 2016-04-01 at 3.52.32 PM.png Screen Shot 2016-04-01 at 3.52.12 PM.png Screen Shot 2016-04-01 at 3.52.00 PM.png > Unify human readable numbers in the web UI > --- > > Key: HBASE-15586 > URL: https://issues.apache.org/jira/browse/HBASE-15586 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: Screen Shot 2016-04-01 at 3.52.00 PM.png, Screen Shot > 2016-04-01 at 3.52.12 PM.png, Screen Shot 2016-04-01 at 3.52.32 PM.png, > Screen Shot 2016-04-01 at 3.52.38 PM.png, Screen Shot 2016-04-01 at 3.52.49 > PM.png, hbase-15586-v1.patch > > > I was looking at something else in the regionserver web ui trying to > understand the WAL size, and we are reporting that as raw bytes, not in MB / > GB range. Did a quick sweep to unify all the human-readable representations > in the UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15586) Unify human readable numbers in the web UI
[ https://issues.apache.org/jira/browse/HBASE-15586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15586: -- Attachment: hbase-15586-v1.patch I think I have covered everything, but a second look would be good. > Unify human readable numbers in the web UI > --- > > Key: HBASE-15586 > URL: https://issues.apache.org/jira/browse/HBASE-15586 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: hbase-15586-v1.patch > > > I was looking at something else in the regionserver web ui trying to > understand the WAL size, and we are reporting that as raw bytes, not in MB / > GB range. Did a quick sweep to unify all the human-readable representations > in the UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15586) Unify human readable numbers in the web UI
Enis Soztutar created HBASE-15586: - Summary: Unify human readable numbers in the web UI Key: HBASE-15586 URL: https://issues.apache.org/jira/browse/HBASE-15586 Project: HBase Issue Type: Bug Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 2.0.0, 1.3.0, 1.4.0 I was looking at something else in the regionserver web ui trying to understand the WAL size, and we are reporting that as raw bytes, not in MB / GB range. Did a quick sweep to unify all the human-readable representations in the UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15505) ReplicationPeerConfig should be builder-style
[
https://issues.apache.org/jira/browse/HBASE-15505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222480#comment-15222480
]
Hadoop QA commented on HBASE-15505:
---
| (/) *{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 3 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 29s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 19s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
1s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
11s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
58s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 19s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
22s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 30s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 30s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 20s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 20s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
3s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
12s {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}
27m 52s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
17s {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 18s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 56s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 42m 58s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12796607/HBASE-15505.4.patch |
| JIRA Issue | HBASE-15505 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux asf906.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/component/dev-support/hbase-personality.sh
|
| git revision | master / 25419d8 |
| 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/1270/testReport/ |
| modules | C: hbase-client U:
[jira] [Updated] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-15585: - Attachment: HBASE-15585.patch [~enis] [~stack] can you guys please review? > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15585) RegionServer coprocessors are not flexible enough
[ https://issues.apache.org/jira/browse/HBASE-15585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-15585: - Status: Patch Available (was: Open) > RegionServer coprocessors are not flexible enough > - > > Key: HBASE-15585 > URL: https://issues.apache.org/jira/browse/HBASE-15585 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-15585.patch > > > While you can do all kinds of things with coprocessors, like arbitrarily > discard memstore data or replace files randomly during compaction, I believe > the ultimate power and flexibility is not there. The patch aims to address > this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15585) RegionServer coprocessors are not flexible enough
Sergey Shelukhin created HBASE-15585: Summary: RegionServer coprocessors are not flexible enough Key: HBASE-15585 URL: https://issues.apache.org/jira/browse/HBASE-15585 Project: HBase Issue Type: Bug Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin While you can do all kinds of things with coprocessors, like arbitrarily discard memstore data or replace files randomly during compaction, I believe the ultimate power and flexibility is not there. The patch aims to address this shortcoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15411) Rewrite backup with Procedure V2 - phase 1
[
https://issues.apache.org/jira/browse/HBASE-15411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222452#comment-15222452
]
Ted Yu commented on HBASE-15411:
Rerun all the backup tests:
{code}
Running org.apache.hadoop.hbase.backup.TestFullRestore
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 144.992 sec -
in org.apache.hadoop.hbase.backup.TestFullRestore
Running org.apache.hadoop.hbase.backup.TestFullBackup
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 96.622 sec - in
org.apache.hadoop.hbase.backup.TestFullBackup
Running org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 70.388 sec - in
org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
Running org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.084 sec - in
org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
Running org.apache.hadoop.hbase.backup.TestIncrementalBackup
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 209.184 sec -
in org.apache.hadoop.hbase.backup.TestIncrementalBackup
Running org.apache.hadoop.hbase.backup.TestBackupSystemTable
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 30.809 sec - in
org.apache.hadoop.hbase.backup.TestBackupSystemTable
Running org.apache.hadoop.hbase.backup.TestHFileArchiving
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 90.075 sec - in
org.apache.hadoop.hbase.backup.TestHFileArchiving
Running org.apache.hadoop.hbase.backup.TestRemoteRestore
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 66.449 sec - in
org.apache.hadoop.hbase.backup.TestRemoteRestore
Running org.apache.hadoop.hbase.backup.TestRemoteBackup
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 59.732 sec - in
org.apache.hadoop.hbase.backup.TestRemoteBackup
Running org.apache.hadoop.hbase.backup.TestBackupLogCleaner
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 75.088 sec - in
org.apache.hadoop.hbase.backup.TestBackupLogCleaner
{code}
> Rewrite backup with Procedure V2 - phase 1
> --
>
> Key: HBASE-15411
> URL: https://issues.apache.org/jira/browse/HBASE-15411
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 15411-v1.txt, 15411-v11.txt, 15411-v12.txt,
> 15411-v13.txt, 15411-v14.txt, 15411-v15.txt, 15411-v16.txt, 15411-v18.txt,
> 15411-v22.txt, 15411-v3.txt, 15411-v5.txt, 15411-v6.txt, 15411-v7.txt,
> 15411-v9.txt, FullTableBackupProcedure.java
>
>
> Currently full / incremental backup is driven by BackupHandler (see call()
> method for flow).
> This issue is to rewrite the flow using Procedure V2.
> States (enum) for full / incremental backup would be introduced in
> Backup.proto which correspond to the steps performed in BackupHandler#call().
> executeFromState() would pace the backup based on the current state.
> serializeStateData() / deserializeStateData() would be used to persist state
> into procedure WAL.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15582) SnapshotManifestV1 too verbose when there are no regions
[
https://issues.apache.org/jira/browse/HBASE-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222442#comment-15222442
]
Hadoop QA commented on HBASE-15582:
---
| (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} 2m
46s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 45s
{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} 4m
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
29s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 40s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 44s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 48s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
35s {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}
25m 37s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{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} 93m 31s
{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} 144m 15s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12796583/HBASE-15582-v0.patch |
| JIRA Issue | HBASE-15582 |
| 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/component/dev-support/hbase-personality.sh
|
| git revision | master / 25419d8 |
| 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
[jira] [Updated] (HBASE-15505) ReplicationPeerConfig should be builder-style
[
https://issues.apache.org/jira/browse/HBASE-15505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Liptak updated HBASE-15505:
-
Attachment: HBASE-15505.4.patch
> ReplicationPeerConfig should be builder-style
> -
>
> Key: HBASE-15505
> URL: https://issues.apache.org/jira/browse/HBASE-15505
> Project: HBase
> Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Gabor Liptak
> Labels: beginner, beginners
> Fix For: 2.0.0
>
> Attachments: HBASE-15505.1.patch, HBASE-15505.2.patch,
> HBASE-15505.3.patch, HBASE-15505.4.patch
>
>
> Similar to HTD, HCD, {{ReplicationPeerConfig}} should be builder-style:
> {code}
> ReplicationPeerConfig().setFoo(foo).setBar(bar);
> {code}
> See {{TestHTableDescriptor.testClassMethodsAreBuilderStyle()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14703) HTable.mutateRow does not collect stats
[ https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222416#comment-15222416 ] Jesse Yates commented on HBASE-14703: - Sorry, got side-tracked with real life. I don't think I'm going to be able to make 0.98 patch soon. Maybe [~chenheng] feels up to it? > HTable.mutateRow does not collect stats > --- > > Key: HBASE-14703 > URL: https://issues.apache.org/jira/browse/HBASE-14703 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Heng Chen >Assignee: Heng Chen > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: HBASE-14702_v5.2_addendum-addendum.patch, > HBASE-14703-5.2-addendum.patch, HBASE-14703-async.patch, > HBASE-14703-branch-1.patch, HBASE-14703-branch-1.v1.patch, > HBASE-14703-branch-1_v1.patch, HBASE-14703-start.patch, > HBASE-14703-v4.1.patch, HBASE-14703-v4.patch, > HBASE-14703-v6_with-check-and-mutate.patch, HBASE-14703.patch, > HBASE-14703_v1.patch, HBASE-14703_v10.patch, HBASE-14703_v10.patch, > HBASE-14703_v11.patch, HBASE-14703_v12.patch, HBASE-14703_v13.patch, > HBASE-14703_v2.patch, HBASE-14703_v3.patch, HBASE-14703_v5.1.patch, > HBASE-14703_v5.2.patch, HBASE-14703_v5.patch, HBASE-14703_v6-addendum.patch, > HBASE-14703_v6.patch, HBASE-14703_v7.patch, HBASE-14703_v8.patch, > HBASE-14703_v9.patch > > > We are trying to fix the stats implementation, by moving it out of the Result > object and into an Rpc payload (but not the 'cell payload', just as part of > the values returned from the request). This change will also us use easily > switch to AsyncProcess as the executor, and support stats, for nearly all the > rpc calls. However, that means when you upgrade the client or server, you > will lose stats visibility until the other side is upgraded. We could keep > around the Result based stats storage to accommodate the old api and send > both stats back from the server (in each result and in the rpc payload). > Note that we will still be wire compatible - protobufs mean we can just ride > over the lack of information. > The other tricky part of this is that Result has a > non-InterfaceAudience.Private getStatistics() method (along with two > InterfaceAudience.Private addResults and setStatistics methods), so we might > need a release to deprecate the getStats() method before throwing it out? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15411) Rewrite backup with Procedure V2 - phase 1
[ https://issues.apache.org/jira/browse/HBASE-15411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222413#comment-15222413 ] Ted Yu commented on HBASE-15411: Thanks for the review, Matteo, Enis and Stephen. I pushed the modified version to HBASE-7912 branch. > Rewrite backup with Procedure V2 - phase 1 > -- > > Key: HBASE-15411 > URL: https://issues.apache.org/jira/browse/HBASE-15411 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Attachments: 15411-v1.txt, 15411-v11.txt, 15411-v12.txt, > 15411-v13.txt, 15411-v14.txt, 15411-v15.txt, 15411-v16.txt, 15411-v18.txt, > 15411-v22.txt, 15411-v3.txt, 15411-v5.txt, 15411-v6.txt, 15411-v7.txt, > 15411-v9.txt, FullTableBackupProcedure.java > > > Currently full / incremental backup is driven by BackupHandler (see call() > method for flow). > This issue is to rewrite the flow using Procedure V2. > States (enum) for full / incremental backup would be introduced in > Backup.proto which correspond to the steps performed in BackupHandler#call(). > executeFromState() would pace the backup based on the current state. > serializeStateData() / deserializeStateData() would be used to persist state > into procedure WAL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15411) Rewrite backup with Procedure V2 - phase 1
[ https://issues.apache.org/jira/browse/HBASE-15411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15411: --- Summary: Rewrite backup with Procedure V2 - phase 1 (was: Rewrite backup with Procedure V2) > Rewrite backup with Procedure V2 - phase 1 > -- > > Key: HBASE-15411 > URL: https://issues.apache.org/jira/browse/HBASE-15411 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Attachments: 15411-v1.txt, 15411-v11.txt, 15411-v12.txt, > 15411-v13.txt, 15411-v14.txt, 15411-v15.txt, 15411-v16.txt, 15411-v18.txt, > 15411-v22.txt, 15411-v3.txt, 15411-v5.txt, 15411-v6.txt, 15411-v7.txt, > 15411-v9.txt, FullTableBackupProcedure.java > > > Currently full / incremental backup is driven by BackupHandler (see call() > method for flow). > This issue is to rewrite the flow using Procedure V2. > States (enum) for full / incremental backup would be introduced in > Backup.proto which correspond to the steps performed in BackupHandler#call(). > executeFromState() would pace the backup based on the current state. > serializeStateData() / deserializeStateData() would be used to persist state > into procedure WAL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15572) Adding optional timestamp semantics to HBase-Spark
[ https://issues.apache.org/jira/browse/HBASE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Weiqing Yang updated HBASE-15572: - Description: Right now the timestamp is always latest. With this patch, users can select timestamps they want. In this patch, 4 parameters, "timestamp", "minTimestamp", "maxiTimestamp" and "maxVersions" are added to HBaseSparkConf. Users can select a timestamp, they can also select a time range with minimum timestamp and maximum timestamp. A new test for selecting records with different timestamps is added. was: Right now the timestamp is always latest. With this patch, users can select timestamps they want. In this patch, 3 parameters, "timestamp", "minTimestamp" and "maxiTimestamp" are added to HBaseSparkConf. Users can select a timestamp, they can also select a time range with minimum timestamp and maximum timestamp. A new test for selecting records with different timestamps is added. > Adding optional timestamp semantics to HBase-Spark > -- > > Key: HBASE-15572 > URL: https://issues.apache.org/jira/browse/HBASE-15572 > Project: HBase > Issue Type: New Feature > Components: spark >Reporter: Weiqing Yang >Assignee: Weiqing Yang > Fix For: 2.0.0 > > Attachments: HBASE-15572-1.patch, HBASE-15572-2.patch, > HBASE-15572-3.patch, HBASE-15572-4.patch, HBASE-15572-5.patch > > > Right now the timestamp is always latest. With this patch, users can select > timestamps they want. > In this patch, 4 parameters, "timestamp", "minTimestamp", "maxiTimestamp" and > "maxVersions" are added to HBaseSparkConf. Users can select a timestamp, they > can also select a time range with minimum timestamp and maximum timestamp. A > new test for selecting records with different timestamps is added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15572) Adding optional timestamp semantics to HBase-Spark
[ https://issues.apache.org/jira/browse/HBASE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222404#comment-15222404 ] Weiqing Yang commented on HBASE-15572: -- [~busbey][~zhanzhang][~jerryhe] Thanks for your feedback. I have updated the doc. > Adding optional timestamp semantics to HBase-Spark > -- > > Key: HBASE-15572 > URL: https://issues.apache.org/jira/browse/HBASE-15572 > Project: HBase > Issue Type: New Feature > Components: spark >Reporter: Weiqing Yang >Assignee: Weiqing Yang > Fix For: 2.0.0 > > Attachments: HBASE-15572-1.patch, HBASE-15572-2.patch, > HBASE-15572-3.patch, HBASE-15572-4.patch, HBASE-15572-5.patch > > > Right now the timestamp is always latest. With this patch, users can select > timestamps they want. > In this patch, 3 parameters, "timestamp", "minTimestamp" and "maxiTimestamp" > are added to HBaseSparkConf. Users can select a timestamp, they can also > select a time range with minimum timestamp and maximum timestamp. A new test > for selecting records with different timestamps is added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15584) Revisit handling of BackupState#CANCELLED
Ted Yu created HBASE-15584:
--
Summary: Revisit handling of BackupState#CANCELLED
Key: HBASE-15584
URL: https://issues.apache.org/jira/browse/HBASE-15584
Project: HBase
Issue Type: Sub-task
Reporter: Ted Yu
Priority: Minor
During review of HBASE-15411, Enis made the following point:
{code}
nobody puts the backup in cancelled state. setCancelled() is not used. So if I
abort a backup, who writes to the system table the new state?
Not sure whether this is a phase 1 patch issue or due to this patch. We can
open a new jira and address it there if you do not want to do it in this patch.
Also maybe this should be named ABORTED rather than CANCELLED.
{code}
This issue is to decide whether this state should be kept (e.g. through
notification from procedure V2 framework in response to abortion).
If it is to be kept, the state should be renamed ABORTED.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15572) Adding optional timestamp semantics to HBase-Spark
[ https://issues.apache.org/jira/browse/HBASE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Weiqing Yang updated HBASE-15572: - Attachment: HBASE-15572-5.patch > Adding optional timestamp semantics to HBase-Spark > -- > > Key: HBASE-15572 > URL: https://issues.apache.org/jira/browse/HBASE-15572 > Project: HBase > Issue Type: New Feature > Components: spark >Reporter: Weiqing Yang >Assignee: Weiqing Yang > Fix For: 2.0.0 > > Attachments: HBASE-15572-1.patch, HBASE-15572-2.patch, > HBASE-15572-3.patch, HBASE-15572-4.patch, HBASE-15572-5.patch > > > Right now the timestamp is always latest. With this patch, users can select > timestamps they want. > In this patch, 3 parameters, "timestamp", "minTimestamp" and "maxiTimestamp" > are added to HBaseSparkConf. Users can select a timestamp, they can also > select a time range with minimum timestamp and maximum timestamp. A new test > for selecting records with different timestamps is added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15583) Discuss mutable vs immutable HTableDescriptor
Gabor Liptak created HBASE-15583: Summary: Discuss mutable vs immutable HTableDescriptor Key: HBASE-15583 URL: https://issues.apache.org/jira/browse/HBASE-15583 Project: HBase Issue Type: Sub-task Affects Versions: 2.0.0 Reporter: Gabor Liptak Priority: Minor >From [~enis] in https://issues.apache.org/jira/browse/HBASE-15505: PS Should UnmodifyableHTableDescriptor be renamed to UnmodifiableHTableDescriptor? It should be named ImmutableHTableDescriptor to be consistent with collections naming. Let's do this as a subtask of the parent jira, not here. Thinking about it though, why would we return an Immutable HTD in HTable.getTableDescriptor() versus a mutable HTD in Admin.getTableDescriptor(). It does not make sense. Should we just get rid of the Immutable ones? We also have UnmodifyableHRegionInfo which is not used at the moment it seems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15582) SnapshotManifestV1 too verbose when there are no regions
[ https://issues.apache.org/jira/browse/HBASE-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222391#comment-15222391 ] Jonathan Hsieh commented on HBASE-15582: +1 > SnapshotManifestV1 too verbose when there are no regions > > > Key: HBASE-15582 > URL: https://issues.apache.org/jira/browse/HBASE-15582 > Project: HBase > Issue Type: Bug > Components: master, snapshots >Affects Versions: 2.0.0, 1.2.0, 1.3.0, 1.1.4, 0.98.16.1 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Trivial > Attachments: HBASE-15582-v0.patch > > > swap the INFO for DEBUG in SnapshotManifestV1.loadRegionManifests() otherwise > the cleaner will spam everyone for no reason -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15191) CopyTable and VerifyReplication - Option to specify batch size, versions
[ https://issues.apache.org/jira/browse/HBASE-15191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-15191: --- Fix Version/s: 0.98.19 > CopyTable and VerifyReplication - Option to specify batch size, versions > > > Key: HBASE-15191 > URL: https://issues.apache.org/jira/browse/HBASE-15191 > Project: HBase > Issue Type: Improvement > Components: Replication >Affects Versions: 0.98.16.1 >Reporter: Parth Shah >Assignee: Parth Shah >Priority: Minor > Fix For: 2.0.0, 0.98.19, 1.4.0 > > Attachments: HBASE_15191.patch, HBASE_15191.patch > > > Need option to specify batch size for CopyTable and VerifyReplication. We > are working on patch for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15548) SyncTable: sourceHashDir is supposed to be optional but won't work without
[ https://issues.apache.org/jira/browse/HBASE-15548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-15548: --- Fix Version/s: 0.98.19 > SyncTable: sourceHashDir is supposed to be optional but won't work without > --- > > Key: HBASE-15548 > URL: https://issues.apache.org/jira/browse/HBASE-15548 > Project: HBase > Issue Type: Bug > Components: Replication >Affects Versions: 1.2.0 > Environment: Ubuntu 12.04 >Reporter: My Ho >Assignee: Dave Latham >Priority: Minor > Fix For: 2.0.0, 0.98.19, 1.4.0 > > Attachments: HBASE-15548.patch > > > 1) SyncTable code is contradictory. Usage said sourcehashdir is optional > (https://github.com/apache/hbase/blob/ad3feaa44800f10d102255a240c38ccf23a82d49/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/SyncTable.java#L687). > However, the command won't run if sourcehashdir is missing > (https://github.com/apache/hbase/blob/ad3feaa44800f10d102255a240c38ccf23a82d49/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/SyncTable.java#L83-L85) > > 2) There is no documentation on how to create the desired sourcehash -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14703) HTable.mutateRow does not collect stats
[ https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222378#comment-15222378 ] Andrew Purtell commented on HBASE-14703: Any interest in providing a 0.98 patch? Or should I think about doing a backport? > HTable.mutateRow does not collect stats > --- > > Key: HBASE-14703 > URL: https://issues.apache.org/jira/browse/HBASE-14703 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Heng Chen >Assignee: Heng Chen > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: HBASE-14702_v5.2_addendum-addendum.patch, > HBASE-14703-5.2-addendum.patch, HBASE-14703-async.patch, > HBASE-14703-branch-1.patch, HBASE-14703-branch-1.v1.patch, > HBASE-14703-branch-1_v1.patch, HBASE-14703-start.patch, > HBASE-14703-v4.1.patch, HBASE-14703-v4.patch, > HBASE-14703-v6_with-check-and-mutate.patch, HBASE-14703.patch, > HBASE-14703_v1.patch, HBASE-14703_v10.patch, HBASE-14703_v10.patch, > HBASE-14703_v11.patch, HBASE-14703_v12.patch, HBASE-14703_v13.patch, > HBASE-14703_v2.patch, HBASE-14703_v3.patch, HBASE-14703_v5.1.patch, > HBASE-14703_v5.2.patch, HBASE-14703_v5.patch, HBASE-14703_v6-addendum.patch, > HBASE-14703_v6.patch, HBASE-14703_v7.patch, HBASE-14703_v8.patch, > HBASE-14703_v9.patch > > > We are trying to fix the stats implementation, by moving it out of the Result > object and into an Rpc payload (but not the 'cell payload', just as part of > the values returned from the request). This change will also us use easily > switch to AsyncProcess as the executor, and support stats, for nearly all the > rpc calls. However, that means when you upgrade the client or server, you > will lose stats visibility until the other side is upgraded. We could keep > around the Result based stats storage to accommodate the old api and send > both stats back from the server (in each result and in the rpc payload). > Note that we will still be wire compatible - protobufs mean we can just ride > over the lack of information. > The other tricky part of this is that Result has a > non-InterfaceAudience.Private getStatistics() method (along with two > InterfaceAudience.Private addResults and setStatistics methods), so we might > need a release to deprecate the getStats() method before throwing it out? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15475) Allow TimestampsFilter to provide a seek hint
[ https://issues.apache.org/jira/browse/HBASE-15475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-15475: --- Fix Version/s: 0.98.19 > Allow TimestampsFilter to provide a seek hint > - > > Key: HBASE-15475 > URL: https://issues.apache.org/jira/browse/HBASE-15475 > Project: HBase > Issue Type: Improvement > Components: Client, Filters, regionserver >Affects Versions: 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.3.0, 0.98.19, 1.4.0 > > Attachments: HBASE-15475-branch-1.patch, HBASE-15475-v1.patch, > HBASE-15475-v2.patch, HBASE-15475-v3.patch, HBASE-15475-v4.patch, > HBASE-15475-v5.patch, HBASE-15475.patch > > > If a user wants to read specific timestamps currently it's a very linear > scan. This is so that all deletes can be respected. However if the user > doesn't care about deletes it can dramatically speed up the request to seek. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15212) RRCServer should enforce max request size
[ https://issues.apache.org/jira/browse/HBASE-15212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222357#comment-15222357 ] Enis Soztutar commented on HBASE-15212: --- bq. Seems this cause TestAsyncIPC.testRpcMaxRequestSize fail? I've ran that test locally before commit (see https://issues.apache.org/jira/browse/HBASE-15212?focusedCommentId=15207492=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15207492). It seemed like a flaky test (because I've seen the failure before this if I remember right). But maybe there is an issue. > RRCServer should enforce max request size > -- > > Key: HBASE-15212 > URL: https://issues.apache.org/jira/browse/HBASE-15212 > Project: HBase > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.3.0, 0.98.19, 1.4.0 > > Attachments: hbase-15212_v1.patch, hbase-15212_v1.patch, > hbase-15212_v2.patch > > > A TODO from HBASE-15177 was that we are not protecting the RPCServer in case > an RPC request with a very large size is received. This might cause the > server to go OOM because we are allocating the RPC serialization into a BB. > Instead we should reject the RPC and close the connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15236) Inconsistent cell reads over multiple bulk-loaded HFiles
[
https://issues.apache.org/jira/browse/HBASE-15236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222342#comment-15222342
]
Jonathan Hsieh commented on HBASE-15236:
Quick nits:
* Can you make a comment at metadataMap's declaration saying that this is only
read by reader.loadinfo and never modified?This justifies why your copy
constructor can take a reference instead of a full copy of the metadataMap.
* Store file scanner is LimitedPrivate("Coproc") and you change the
StoreFileScanner constructor signature. Maybe add a version of the old
signature with 0 as the priority by default?
Let's have [~saint@gmail.com] double check if he is ok with the rename of
sequenceId to priorityId.
> Inconsistent cell reads over multiple bulk-loaded HFiles
>
>
> Key: HBASE-15236
> URL: https://issues.apache.org/jira/browse/HBASE-15236
> Project: HBase
> Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: HBASE-15236-master-v2.patch,
> HBASE-15236-master-v3.patch, HBASE-15236-master-v4.patch,
> HBASE-15236-master-v5.patch, HBASE-15236-master-v6.patch,
> HBASE-15236-master-v7.patch, HBASE-15236.patch, TestWithSingleHRegion.java,
> tables_data.zip
>
>
> If there are two bulkloaded hfiles in a region with same seqID, same
> timestamps and duplicate keys*, get and scan may return different values for
> a key. Not sure how this would happen, but one of our customer uploaded a
> dataset with 2 files in a single region and both having same bulk load
> timestamp. These files are small ~50M (I couldn't find any setting for max
> file size that could lead to 2 files). The range of keys in two hfiles are
> overlapping to some extent, but not fully (so the two files are because of
> region merge).
> In such a case, depending on file sizes (used in
> StoreFile.Comparators.SEQ_ID), we may get different values for the same cell
> (say "r", "cf:50") depending on what we call: get "r" "cf:50" or get "r"
> "cf:".
> To replicate this, i ran ImportTsv twice with 2 different csv files but same
> timestamp (-Dimporttsv.timestamp=1). Collected two resulting hfiles in a
> single directory and loaded with LoadIncrementalHFiles. Here are the commands.
> {noformat}
> //CSV files should be in hdfs:///user/hbase/tmp
> sudo -u hbase hbase org.apache.hadoop.hbase.mapreduce.ImportTsv
> -Dimporttsv.columns=HBASE_ROW_KEY,c:1,c:2,c:3,c:4,c:5,c:6
> -Dimporttsv.separator='|' -Dimporttsv.timestamp=1
> -Dimporttsv.bulk.output=hdfs:///user/hbase/1 t tmp
> {noformat}
> tables_data.zip contains three tables: t, t2, and t3.
> To load these tables and test with them, use the attached
> TestWithSingleHRegion.java. (Change ROOT_DIR and TABLE_NAME variables
> appropriately)
> Hfiles for table 't':
> 1) 07922ac90208445883b2ddc89c424c89 : length = 1094: KVs = (c:5, 55) (c:6, 66)
> 2) 143137fa4fa84625b4e8d1d84a494f08 : length = 1192: KVs = (c:1, 1) (c:2, 2)
> (c:3, 3) (c:4, 4) (c:5, 5) (c:6, 6)
> Get returns 5 where as Scan returns 55.
> On the other hand if I make the first hfile, the one with values 55 and 66
> bigger in size than second hfile, then:
> Get returns 55 where as Scan returns 55.
> This can be seen in table 't2'.
> Weird things:
> 1. Get consistently returns values from larger hfile.
> 2. Scan consistently returns 55.
> Reason:
> Explanation 1: We add StoreFileScanners to heap by iterating over list of
> store files which is kept sorted in DefaultStoreFileManger using
> StoreFile.Comparators.SEQ_ID. It sorts the file first by increasing seq id,
> then by decreasing filesize. So our larger files sizes are always in the
> start.
> Explanation 2: In KeyValueHeap.next(), if both current and this.heap.peek()
> scanners (type is StoreFileScanner in this case) point to KVs which compare
> as equal, we put back the current scanner into heap, and call pollRealKV() to
> get new one. While inserting, KVScannerComparator is used which compares the
> two (one already in heap and the one being inserted) as equal and inserts it
> after the existing one. \[1\]
> Say s1 is scanner over first hfile and s2 over second.
> 1. We scan with s2 to get values 1, 2, 3, 4
> 2. see that both scanners have c:5 as next key, put current scanner s2 back
> in heap, take s1 out
> 4. return 55, advance s1 to key c:6
> 5. compare c:6 to c:5, put back s2 in heap since it has larger key, take out
> s1
> 6. ignore it's value (there is code for that too), advance s2 to c:6
> Go back to step 2 with both scanners having c:6 as next key
> This is wrong because if we add a key between c:4 and c:5 to first hfile, say
> (c:44, foo) which makes s1 as the 'current' scanner when we hit step 2, then
> we'll get the values - 1, 2, 3, 4, foo, 5, 6.
> (try table t3)
> Fix:
> Assign priority ids to StoreFileScanners when
[jira] [Updated] (HBASE-15212) RRCServer should enforce max request size
[ https://issues.apache.org/jira/browse/HBASE-15212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-15212: --- Fix Version/s: 0.98.19 > RRCServer should enforce max request size > -- > > Key: HBASE-15212 > URL: https://issues.apache.org/jira/browse/HBASE-15212 > Project: HBase > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.3.0, 0.98.19, 1.4.0 > > Attachments: hbase-15212_v1.patch, hbase-15212_v1.patch, > hbase-15212_v2.patch > > > A TODO from HBASE-15177 was that we are not protecting the RPCServer in case > an RPC request with a very large size is received. This might cause the > server to go OOM because we are allocating the RPC serialization into a BB. > Instead we should reject the RPC and close the connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15576) Support stateless scanning and scanning cursor
[
https://issues.apache.org/jira/browse/HBASE-15576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222315#comment-15222315
]
stack commented on HBASE-15576:
---
bq. we think we should save mvcc in HFile to solve some issues on replication.
We have been in a bit of an in-between place here for way too long. They are
'there' sometimes. They are there when we flush so that any ongoing scanners
that span memory and hfiles will do the right thing. But then they get
compacted away after some period of time replaced by a global sequenceid on the
whole hfile.
Would make things easier to reason about at recovery and replication time if
always present. Folks complain about size they occupy.
There is also the hybrid logical clocks ticket which is related (overload
timestamp to do sequenceid too) but that 'd be 2.0.
> Support stateless scanning and scanning cursor
> --
>
> Key: HBASE-15576
> URL: https://issues.apache.org/jira/browse/HBASE-15576
> Project: HBase
> Issue Type: New Feature
>Reporter: Phil Yang
>Assignee: Phil Yang
>
> After 1.1.0 released, we have partial and heartbeat protocol in scanning to
> prevent responding large data or timeout. Now for ResultScanner.next(), we
> may block for longer time larger than timeout settings to get a Result if the
> row is very large, or filter is sparse, or there are too many delete markers
> in files.
> However, in some scenes, we don't want it to be blocked for too long. For
> example, a web service which handles requests from mobile devices whose
> network is not stable and we can not set timeout too long(eg. only 5 seconds)
> between mobile and web service. This service will scan rows from HBase and
> return it to mobile devices. In this scene, the simplest way is to make the
> web service stateless. Apps in mobile devices will send several requests one
> by one to get the data until enough just like paging a list. In each request
> it will carry a start position which depends on the last result from web
> service. Different requests can be sent to different web service server
> because it is stateless.
> Therefore, the stateless web service need a cursor from HBase telling where
> we have scanned in RegionScanner when HBase client receives an empty
> heartbeat. And the service will return the cursor to mobile device although
> the response has no data. In next request we can start at the position of
> cursor, without the cursor we have to scan from last returned result and we
> may timeout forever. And of course even if the heartbeat message is not empty
> we can still use cursor to prevent re-scan the same rows/cells which has beed
> skipped.
> Obviously, we will give up consistency for scanning because even HBase client
> is also stateless, but it is acceptable in this scene. And maybe we can keep
> mvcc in cursor so we can get a consistent view?
> HBASE-13099 had some discussion, but it has no further progress by now.
> API:
> In Scan we need a new method setStateless to make the scanning stateless and
> need another timeout setting for stateless scanning. In this mode we will not
> block ResultScanner.next() longer than this timeout setting. And we will
> return Results in next() as usual but the last Result (or only Result if we
> receive empty heartbeat) has a special flag to mark it a cursor. The cursor
> Result has only one Cell. Users can scan like this:
> {code}
> while( r = scanner.next() && r != null && !r.isCursor()){
> //just like before
> }
> if(r != null){
> // scanning is not end, it is a cursor
> } else {
> // scanning is end
> }
> scanner.close()
> {code}
> Implementation:
> We will have two options to support stateless scanning:
> Only one rpc like small scanning, not supporting batch/partials and cursor is
> row level. It is simple to implementation.
> Support big scanning with several rpc requests, supporting batch/partials and
> cursor is cell level. It is a little complex because we need seek at server
> side and we should make sure total time of rpc requests not exceed timeout
> setting.
> Or we can make it by two phases, support one-shot first?
> Any thoughts? Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15581) Reduce garbage created by PB in write path
[ https://issues.apache.org/jira/browse/HBASE-15581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222305#comment-15222305 ] stack commented on HBASE-15581: --- Hurray. Want to go to PB2.6? We'll have to shade? > Reduce garbage created by PB in write path > -- > > Key: HBASE-15581 > URL: https://issues.apache.org/jira/browse/HBASE-15581 > Project: HBase > Issue Type: Sub-task >Reporter: Anoop Sam John >Assignee: Anoop Sam John > > Changes such that PB code will not make much garbage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15572) Adding optional timestamp semantics to HBase-Spark
[ https://issues.apache.org/jira/browse/HBASE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1595#comment-1595 ] Jerry He commented on HBASE-15572: -- The patch also seems to have added MAX VERSION support. Don't miss it in the Description or the doc. > Adding optional timestamp semantics to HBase-Spark > -- > > Key: HBASE-15572 > URL: https://issues.apache.org/jira/browse/HBASE-15572 > Project: HBase > Issue Type: New Feature > Components: spark >Reporter: Weiqing Yang >Assignee: Weiqing Yang > Fix For: 2.0.0 > > Attachments: HBASE-15572-1.patch, HBASE-15572-2.patch, > HBASE-15572-3.patch, HBASE-15572-4.patch > > > Right now the timestamp is always latest. With this patch, users can select > timestamps they want. > In this patch, 3 parameters, "timestamp", "minTimestamp" and "maxiTimestamp" > are added to HBaseSparkConf. Users can select a timestamp, they can also > select a time range with minimum timestamp and maximum timestamp. A new test > for selecting records with different timestamps is added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14870) Backport namespace permissions to 98 branch
[ https://issues.apache.org/jira/browse/HBASE-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14870: --- Description: Backport namespace permissions to 0.98. (was: Backport namespace permissions to 0.98. The new permission checks will be disabled by default for behavioral compatibility with previous releases, like what we did when we introduced enforcement of the EXEC permission. ) > Backport namespace permissions to 98 branch > --- > > Key: HBASE-14870 > URL: https://issues.apache.org/jira/browse/HBASE-14870 > Project: HBase > Issue Type: Task >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 0.98.19 > > Attachments: HBASE-14870-0.98.patch > > > Backport namespace permissions to 0.98. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14870) Backport namespace permissions to 98 branch
[ https://issues.apache.org/jira/browse/HBASE-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14870: --- Attachment: HBASE-14870-0.98.patch Attaching patch. This is a collection of backported changes. Each change is individually available for inspection at https://github.com/apurtell/hbase/commits/HBASE-14870-0.98 . Look for the group of commits on Apr 1, 2016 > Backport namespace permissions to 98 branch > --- > > Key: HBASE-14870 > URL: https://issues.apache.org/jira/browse/HBASE-14870 > Project: HBase > Issue Type: Task >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 0.98.19 > > Attachments: HBASE-14870-0.98.patch > > > Backport namespace permissions to 0.98. The new permission checks will be > disabled by default for behavioral compatibility with previous releases, like > what we did when we introduced enforcement of the EXEC permission. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14870) Backport namespace permissions to 98 branch
[ https://issues.apache.org/jira/browse/HBASE-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14870: --- Status: Patch Available (was: Open) > Backport namespace permissions to 98 branch > --- > > Key: HBASE-14870 > URL: https://issues.apache.org/jira/browse/HBASE-14870 > Project: HBase > Issue Type: Task >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 0.98.19 > > Attachments: HBASE-14870-0.98.patch > > > Backport namespace permissions to 0.98. The new permission checks will be > disabled by default for behavioral compatibility with previous releases, like > what we did when we introduced enforcement of the EXEC permission. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14870) Backport namespace permissions to 98 branch
[ https://issues.apache.org/jira/browse/HBASE-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1593#comment-1593 ] Andrew Purtell commented on HBASE-14870: [~lhofhansl] > Backport namespace permissions to 98 branch > --- > > Key: HBASE-14870 > URL: https://issues.apache.org/jira/browse/HBASE-14870 > Project: HBase > Issue Type: Task >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 0.98.19 > > Attachments: HBASE-14870-0.98.patch > > > Backport namespace permissions to 0.98. The new permission checks will be > disabled by default for behavioral compatibility with previous releases, like > what we did when we introduced enforcement of the EXEC permission. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15187) Integrate CSRF prevention filter to REST gateway
[ https://issues.apache.org/jira/browse/HBASE-15187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15187: --- Attachment: HBASE-15187.v10.patch Patch v10 adds description of the feature to new subsection in external_apis.adoc under REST section. > Integrate CSRF prevention filter to REST gateway > > > Key: HBASE-15187 > URL: https://issues.apache.org/jira/browse/HBASE-15187 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0 > > Attachments: HBASE-15187-branch-1.v13.patch, HBASE-15187.v1.patch, > HBASE-15187.v10.patch, HBASE-15187.v10.patch, HBASE-15187.v11.patch, > HBASE-15187.v12.patch, HBASE-15187.v13.patch, HBASE-15187.v2.patch, > HBASE-15187.v3.patch, HBASE-15187.v4.patch, HBASE-15187.v5.patch, > HBASE-15187.v6.patch, HBASE-15187.v7.patch, HBASE-15187.v8.patch, > HBASE-15187.v9.patch > > > HADOOP-12691 introduced a filter in Hadoop Common to help REST APIs guard > against cross-site request forgery attacks. > This issue tracks the integration of that filter into HBase REST gateway. > From REST section of refguide: > To delete a table, use a DELETE request with the /schema endpoint: > http://example.com:8000/schema > Suppose an attacker hosts a malicious web form on a domain under his control. > The form uses the DELETE action targeting a REST URL. Through social > engineering, the attacker tricks an authenticated user into accessing the > form and submitting it. > The browser sends the HTTP DELETE request to the REST gateway. > At REST gateway, the call is executed and user table is dropped -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15562) Gc pause increases when the incoming requests are pooled
[ https://issues.apache.org/jira/browse/HBASE-15562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1551#comment-1551 ] stack commented on HBASE-15562: --- SurvivorRatio? We'd be making less garbage when using pool? So why would messing w/ SurvivorRatio help? (Trying to understand). Where you think the increased pause is coming from [~anoop.hbase]? Thanks. > Gc pause increases when the incoming requests are pooled > > > Key: HBASE-15562 > URL: https://issues.apache.org/jira/browse/HBASE-15562 > Project: HBase > Issue Type: Sub-task >Reporter: ramkrishna.s.vasudevan > > This JIRA is to analyse why the GC pause time increases on introducing a BB > pool on the request side. This JIRA aims to track down the reason behind it. > Having HBASE-15180 has an increased effect in this GC pause time along with > the Bb pool on the request side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15572) Adding optional timestamp semantics to HBase-Spark
[ https://issues.apache.org/jira/browse/HBASE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1549#comment-1549 ] Sean Busbey commented on HBASE-15572: - Thanks for the pointer [~zhanzhang]. I've upgraded that jira to blocker. It would be much better to incorporate the need for documentation into the various jiras as incremental improvements. Keeping it in a different jira makes it substantially harder to get in-progress Spark support into branch-1. I'll have to scope out how bad the gap is in the next couple of weeks so we can decide if hbase-spark will make it into the 1.3 release. > Adding optional timestamp semantics to HBase-Spark > -- > > Key: HBASE-15572 > URL: https://issues.apache.org/jira/browse/HBASE-15572 > Project: HBase > Issue Type: New Feature > Components: spark >Reporter: Weiqing Yang >Assignee: Weiqing Yang > Fix For: 2.0.0 > > Attachments: HBASE-15572-1.patch, HBASE-15572-2.patch, > HBASE-15572-3.patch, HBASE-15572-4.patch > > > Right now the timestamp is always latest. With this patch, users can select > timestamps they want. > In this patch, 3 parameters, "timestamp", "minTimestamp" and "maxiTimestamp" > are added to HBaseSparkConf. Users can select a timestamp, they can also > select a time range with minimum timestamp and maximum timestamp. A new test > for selecting records with different timestamps is added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15473) Documentation for the usage of hbase dataframe user api (JSON, Avro, etc)
[ https://issues.apache.org/jira/browse/HBASE-15473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-15473: Fix Version/s: 2.0.0 > Documentation for the usage of hbase dataframe user api (JSON, Avro, etc) > - > > Key: HBASE-15473 > URL: https://issues.apache.org/jira/browse/HBASE-15473 > Project: HBase > Issue Type: Sub-task > Components: documentation, spark >Reporter: Zhan Zhang >Priority: Blocker > Fix For: 2.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15473) Documentation for the usage of hbase dataframe user api (JSON, Avro, etc)
[ https://issues.apache.org/jira/browse/HBASE-15473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-15473: Priority: Blocker (was: Critical) > Documentation for the usage of hbase dataframe user api (JSON, Avro, etc) > - > > Key: HBASE-15473 > URL: https://issues.apache.org/jira/browse/HBASE-15473 > Project: HBase > Issue Type: Sub-task > Components: documentation, spark >Reporter: Zhan Zhang >Priority: Blocker > Fix For: 2.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15572) Adding optional timestamp semantics to HBase-Spark
[ https://issues.apache.org/jira/browse/HBASE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1542#comment-1542 ] Zhan Zhang commented on HBASE-15572: [~WeiqingYang] Can you please add a description in the ./src/main/asciidoc/_chapters/spark.adoc as requested. [~busbey] There is a document JIRA opened for the new Dataframe user interface and features. The PR is not sent yet, because currently there is still a number of place needed to be changed in the DataFrame support for HBase. Once it is done, a more complete doc will be sent for the community review. To make the work more trackable, I create a link for this jira to https://issues.apache.org/jira/browse/HBASE-14789. HBASE-15473: Documentation for the usage of hbase dataframe user api (JSON, Avro, etc) > Adding optional timestamp semantics to HBase-Spark > -- > > Key: HBASE-15572 > URL: https://issues.apache.org/jira/browse/HBASE-15572 > Project: HBase > Issue Type: New Feature > Components: spark >Reporter: Weiqing Yang >Assignee: Weiqing Yang > Fix For: 2.0.0 > > Attachments: HBASE-15572-1.patch, HBASE-15572-2.patch, > HBASE-15572-3.patch, HBASE-15572-4.patch > > > Right now the timestamp is always latest. With this patch, users can select > timestamps they want. > In this patch, 3 parameters, "timestamp", "minTimestamp" and "maxiTimestamp" > are added to HBaseSparkConf. Users can select a timestamp, they can also > select a time range with minimum timestamp and maximum timestamp. A new test > for selecting records with different timestamps is added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15582) SnapshotManifestV1 too verbose when there are no regions
[ https://issues.apache.org/jira/browse/HBASE-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-15582: Status: Patch Available (was: Open) > SnapshotManifestV1 too verbose when there are no regions > > > Key: HBASE-15582 > URL: https://issues.apache.org/jira/browse/HBASE-15582 > Project: HBase > Issue Type: Bug > Components: master, snapshots >Affects Versions: 0.98.16.1, 1.1.4, 1.2.0, 2.0.0, 1.3.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Attachments: HBASE-15582-v0.patch > > > swap the INFO for DEBUG in SnapshotManifestV1.loadRegionManifests() otherwise > the cleaner will spam everyone for no reason -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15582) SnapshotManifestV1 too verbose when there are no regions
[ https://issues.apache.org/jira/browse/HBASE-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-15582: Priority: Trivial (was: Major) > SnapshotManifestV1 too verbose when there are no regions > > > Key: HBASE-15582 > URL: https://issues.apache.org/jira/browse/HBASE-15582 > Project: HBase > Issue Type: Bug > Components: master, snapshots >Affects Versions: 2.0.0, 1.2.0, 1.3.0, 1.1.4, 0.98.16.1 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Trivial > Attachments: HBASE-15582-v0.patch > > > swap the INFO for DEBUG in SnapshotManifestV1.loadRegionManifests() otherwise > the cleaner will spam everyone for no reason -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15582) SnapshotManifestV1 too verbose when there are no regions
[ https://issues.apache.org/jira/browse/HBASE-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-15582: Component/s: master > SnapshotManifestV1 too verbose when there are no regions > > > Key: HBASE-15582 > URL: https://issues.apache.org/jira/browse/HBASE-15582 > Project: HBase > Issue Type: Bug > Components: master, snapshots >Affects Versions: 2.0.0, 1.2.0, 1.3.0, 1.1.4, 0.98.16.1 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Trivial > Attachments: HBASE-15582-v0.patch > > > swap the INFO for DEBUG in SnapshotManifestV1.loadRegionManifests() otherwise > the cleaner will spam everyone for no reason -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15582) SnapshotManifestV1 too verbose when there are no regions
[ https://issues.apache.org/jira/browse/HBASE-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-15582: Attachment: HBASE-15582-v0.patch > SnapshotManifestV1 too verbose when there are no regions > > > Key: HBASE-15582 > URL: https://issues.apache.org/jira/browse/HBASE-15582 > Project: HBase > Issue Type: Bug > Components: snapshots >Affects Versions: 2.0.0, 1.2.0, 1.3.0, 1.1.4, 0.98.16.1 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Attachments: HBASE-15582-v0.patch > > > swap the INFO for DEBUG in SnapshotManifestV1.loadRegionManifests() otherwise > the cleaner will spam everyone for no reason -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15582) SnapshotManifestV1 too verbose when there are no regions
Matteo Bertozzi created HBASE-15582: --- Summary: SnapshotManifestV1 too verbose when there are no regions Key: HBASE-15582 URL: https://issues.apache.org/jira/browse/HBASE-15582 Project: HBase Issue Type: Bug Components: snapshots Affects Versions: 0.98.16.1, 1.1.4, 1.2.0, 2.0.0, 1.3.0 Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi swap the INFO for DEBUG in SnapshotManifestV1.loadRegionManifests() otherwise the cleaner will spam everyone for no reason -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15572) Adding optional timestamp semantics to HBase-Spark
[ https://issues.apache.org/jira/browse/HBASE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1527#comment-1527 ] Sean Busbey commented on HBASE-15572: - I don't see any docs changes in v4. maybe missed adding it to git? > Adding optional timestamp semantics to HBase-Spark > -- > > Key: HBASE-15572 > URL: https://issues.apache.org/jira/browse/HBASE-15572 > Project: HBase > Issue Type: New Feature > Components: spark >Reporter: Weiqing Yang >Assignee: Weiqing Yang > Fix For: 2.0.0 > > Attachments: HBASE-15572-1.patch, HBASE-15572-2.patch, > HBASE-15572-3.patch, HBASE-15572-4.patch > > > Right now the timestamp is always latest. With this patch, users can select > timestamps they want. > In this patch, 3 parameters, "timestamp", "minTimestamp" and "maxiTimestamp" > are added to HBaseSparkConf. Users can select a timestamp, they can also > select a time range with minimum timestamp and maximum timestamp. A new test > for selecting records with different timestamps is added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15572) Adding optional timestamp semantics to HBase-Spark
[
https://issues.apache.org/jira/browse/HBASE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1523#comment-1523
]
Hadoop QA commented on HBASE-15572:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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 52s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 8s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 0m
36s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 54s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} scalac {color} | {color:green} 0m 54s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 8s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} scalac {color} | {color:green} 1m 8s
{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}
28m 31s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 0m
30s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 0m
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 14s
{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
6s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 38m 48s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12796573/HBASE-15572-4.patch |
| JIRA Issue | HBASE-15572 |
| Optional Tests | asflicense scalac scaladoc unit 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/component/dev-support/hbase-personality.sh
|
| git revision | master / 25419d8 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/1265/testReport/ |
| modules | C: hbase-spark U: hbase-spark |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/1265/console |
| Powered by | Apache Yetus 0.2.0 http://yetus.apache.org |
This message was automatically generated.
> Adding optional timestamp semantics to HBase-Spark
> --
>
> Key: HBASE-15572
> URL: https://issues.apache.org/jira/browse/HBASE-15572
> Project: HBase
> Issue Type: New Feature
> Components: spark
>Reporter: Weiqing Yang
>Assignee: Weiqing Yang
> Fix For: 2.0.0
>
> Attachments: HBASE-15572-1.patch, HBASE-15572-2.patch,
> HBASE-15572-3.patch, HBASE-15572-4.patch
>
>
> Right now the timestamp is always latest. With this patch, users can select
> timestamps they want.
> In this patch, 3 parameters, "timestamp", "minTimestamp" and "maxiTimestamp"
> are added to HBaseSparkConf. Users can select a timestamp, they can also
> select a time range with minimum timestamp and maximum timestamp. A new test
> for selecting records with different timestamps is added.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15564) HashTable job supposedly succeeded but manifest.tmp remain
[ https://issues.apache.org/jira/browse/HBASE-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1500#comment-1500 ] Dave Latham commented on HBASE-15564: - Sure thing, [~mydiemho]. I was referring to the User List (u...@hbase.apache.org) at https://hbase.apache.org/mail-lists.html > HashTable job supposedly succeeded but manifest.tmp remain > -- > > Key: HBASE-15564 > URL: https://issues.apache.org/jira/browse/HBASE-15564 > Project: HBase > Issue Type: Bug > Components: mapreduce, Replication >Affects Versions: 1.2.0 > Environment: Ubuntu 12.04 >Reporter: My Ho > > I'm using org.apache.hadoop.hbase.mapreduce.HashTable to create hashes for > use in SyncTable. Occasionally, the job page in jobhistory will say the job > succeeded, but in my filesystem, I see "manifest.tmp" instead of the expected > "manifest". According to the code[1], the job must have failed, but I don't > see failure anywhere. > [1]https://github.com/apache/hbase/blob/ad3feaa44800f10d102255a240c38ccf23a82d49/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/HashTable.java#L739-L741 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15581) Reduce garbage created by PB in write path
[ https://issues.apache.org/jira/browse/HBASE-15581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-15581: --- Description: Changes such that PB code will not make much garbage. > Reduce garbage created by PB in write path > -- > > Key: HBASE-15581 > URL: https://issues.apache.org/jira/browse/HBASE-15581 > Project: HBase > Issue Type: Sub-task >Reporter: Anoop Sam John >Assignee: Anoop Sam John > > Changes such that PB code will not make much garbage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15581) Reduce garbage created by PB in write path
[ https://issues.apache.org/jira/browse/HBASE-15581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222195#comment-15222195 ] Anoop Sam John commented on HBASE-15581: PB 2.6.0 onwards having some ways of reducing garbage and avoid some copying. eg: CIS#readBytes If the bytes, created the CIS, specified as immutable, it avoids a copy. Right now in write path when Mutation comes as PB object, for field like row, internally PB creates a ByteString representation and on which we call toByteArray() The request bytes 1st copied from socket to a large byte array. PB then create CIS over this. Create ByteString by a copy. On that BS we call toByteArray() which will do again one more copy. We can avoid many copied. > Reduce garbage created by PB in write path > -- > > Key: HBASE-15581 > URL: https://issues.apache.org/jira/browse/HBASE-15581 > Project: HBase > Issue Type: Sub-task >Reporter: Anoop Sam John >Assignee: Anoop Sam John > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15480) Bloom Filter check needs to be more efficient for array
[ https://issues.apache.org/jira/browse/HBASE-15480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222168#comment-15222168 ] John Leach commented on HBASE-15480: Yes. Two initial use cases would be the following... Snapshot Isolation: Use the bloom filter to check a bath of keys for an existing record (conflict detection). Bloom Join: Apply the bloom filters to restrict elements from the shuffle. > Bloom Filter check needs to be more efficient for array > --- > > Key: HBASE-15480 > URL: https://issues.apache.org/jira/browse/HBASE-15480 > Project: HBase > Issue Type: Improvement > Components: Performance >Affects Versions: 1.0.3 >Reporter: Walter Koetke >Assignee: Walter Koetke > Fix For: 1.0.4 > > Attachments: BloomFilterCheckOneByOne.tiff, > HBASE-15480-branch-1.0.patch > > > It is currently inefficient to do lots of bloom filter checks. Each check has > overhead like going to the block cache to retrieve the block and recording > metrics. It would be good to have one bloom filter check api that does a > bunch of checks without so much block retrieval and metrics updates. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15581) Reduce garbage created by PB in write path
Anoop Sam John created HBASE-15581: -- Summary: Reduce garbage created by PB in write path Key: HBASE-15581 URL: https://issues.apache.org/jira/browse/HBASE-15581 Project: HBase Issue Type: Sub-task Reporter: Anoop Sam John Assignee: Anoop Sam John -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15562) Gc pause increases when the incoming requests are pooled
[ https://issues.apache.org/jira/browse/HBASE-15562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222160#comment-15222160 ] Anoop Sam John commented on HBASE-15562: Some update here. After some tuning with SurvivorRatio, we are able to get almost same avg GC pause time and reduced #GC pauses, when the reqs read into BBs that we get from BBBpool..So these are off heap BBs. We have extended PB to support offheap BB. Also we have done an impl of Offheap MSLAB. Will give more test results soon. > Gc pause increases when the incoming requests are pooled > > > Key: HBASE-15562 > URL: https://issues.apache.org/jira/browse/HBASE-15562 > Project: HBase > Issue Type: Sub-task >Reporter: ramkrishna.s.vasudevan > > This JIRA is to analyse why the GC pause time increases on introducing a BB > pool on the request side. This JIRA aims to track down the reason behind it. > Having HBASE-15180 has an increased effect in this GC pause time along with > the Bb pool on the request side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15555) Memory Management
[ https://issues.apache.org/jira/browse/HBASE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222161#comment-15222161 ] Anoop Sam John commented on HBASE-1: Some update here. After some tuning with SurvivorRatio, we are able to get almost same avg GC pause time and reduced #GC pauses, when the reqs read into BBs that we get from BBBpool..So these are off heap BBs. We have extended PB to support offheap BB. Also we have done an impl of Offheap MSLAB. Will give more test results soon. > Memory Management > - > > Key: HBASE-1 > URL: https://issues.apache.org/jira/browse/HBASE-1 > Project: HBase > Issue Type: Umbrella >Reporter: stack > Attachments: download.svg > > > Umbrella issue on memory management. One-stop shop to learn how we're doing > it, tenets, and work to be done. Collect it all in one place so we are > aligned rather than each trying to do it for themselves. > Subtasks include: > + Map of memory allocation and recycling landscape > + Where are we allocating when we could be recycling > + MSLAB and G1GC don't go together? > + Enable MSLAB pool always? > + With offheap allocations, less GC but it runs for longer? > + Better heuristics recycling: e.g. HBASE-15525 OutOfMemory could occur when > using BoundedByteBufferPool during RPC bursts > + See if can do DFSClient buffer reuse: HBASE-15506 > FSDataOutputStream.write() allocates new byte buffer on each operation > What else? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15572) Adding optional timestamp semantics to HBase-Spark
[ https://issues.apache.org/jira/browse/HBASE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222158#comment-15222158 ] Weiqing Yang commented on HBASE-15572: -- Thanks. I have updated the patch. > Adding optional timestamp semantics to HBase-Spark > -- > > Key: HBASE-15572 > URL: https://issues.apache.org/jira/browse/HBASE-15572 > Project: HBase > Issue Type: New Feature > Components: spark >Reporter: Weiqing Yang >Assignee: Weiqing Yang > Fix For: 2.0.0 > > Attachments: HBASE-15572-1.patch, HBASE-15572-2.patch, > HBASE-15572-3.patch, HBASE-15572-4.patch > > > Right now the timestamp is always latest. With this patch, users can select > timestamps they want. > In this patch, 3 parameters, "timestamp", "minTimestamp" and "maxiTimestamp" > are added to HBaseSparkConf. Users can select a timestamp, they can also > select a time range with minimum timestamp and maximum timestamp. A new test > for selecting records with different timestamps is added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15572) Adding optional timestamp semantics to HBase-Spark
[ https://issues.apache.org/jira/browse/HBASE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Weiqing Yang updated HBASE-15572: - Attachment: HBASE-15572-4.patch > Adding optional timestamp semantics to HBase-Spark > -- > > Key: HBASE-15572 > URL: https://issues.apache.org/jira/browse/HBASE-15572 > Project: HBase > Issue Type: New Feature > Components: spark >Reporter: Weiqing Yang >Assignee: Weiqing Yang > Fix For: 2.0.0 > > Attachments: HBASE-15572-1.patch, HBASE-15572-2.patch, > HBASE-15572-3.patch, HBASE-15572-4.patch > > > Right now the timestamp is always latest. With this patch, users can select > timestamps they want. > In this patch, 3 parameters, "timestamp", "minTimestamp" and "maxiTimestamp" > are added to HBaseSparkConf. Users can select a timestamp, they can also > select a time range with minimum timestamp and maximum timestamp. A new test > for selecting records with different timestamps is added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15564) HashTable job supposedly succeeded but manifest.tmp remain
[ https://issues.apache.org/jira/browse/HBASE-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222134#comment-15222134 ] My Ho commented on HBASE-15564: --- [~davelatham] Thank you for the quick response. I'm new to this so not sure what mailing list you are referring to. Could you point me there? Thanks > HashTable job supposedly succeeded but manifest.tmp remain > -- > > Key: HBASE-15564 > URL: https://issues.apache.org/jira/browse/HBASE-15564 > Project: HBase > Issue Type: Bug > Components: mapreduce, Replication >Affects Versions: 1.2.0 > Environment: Ubuntu 12.04 >Reporter: My Ho > > I'm using org.apache.hadoop.hbase.mapreduce.HashTable to create hashes for > use in SyncTable. Occasionally, the job page in jobhistory will say the job > succeeded, but in my filesystem, I see "manifest.tmp" instead of the expected > "manifest". According to the code[1], the job must have failed, but I don't > see failure anywhere. > [1]https://github.com/apache/hbase/blob/ad3feaa44800f10d102255a240c38ccf23a82d49/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/HashTable.java#L739-L741 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
