[jira] [Commented] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204485#comment-16204485 ] stack commented on HBASE-19007: --- [~appy] we > 1 + 1 > Align Services Interfaces in Master and RegionServer > > > Key: HBASE-19007 > URL: https://issues.apache.org/jira/browse/HBASE-19007 > Project: HBase > Issue Type: Task >Reporter: stack >Priority: Blocker > > HBASE-18183 adds a CoprocessorRegionServerService to give a view on > RegionServiceServices that is safe to expose to Coprocessors. > On the Master-side, MasterServices becomes an Interface for exposing to > Coprocessors. > We need to align the two. > For background, see > https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18747) Introduce new example and helper classes to tell CP users how to do filtering on scanners
[
https://issues.apache.org/jira/browse/HBASE-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204480#comment-16204480
]
Hudson commented on HBASE-18747:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3883 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/3883/])
HBASE-18747 Introduce new example and helper classes to tell CP users
(zhangduo: rev d653c0bc7f84379ae797ad9dd899214f72a58213)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/InternalScanner.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionObserverInterface.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionObserverScannerOpenHook.java
* (edit) pom.xml
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/KeyValueHeap.java
* (add)
hbase-examples/src/main/java/org/apache/hadoop/hbase/coprocessor/example/DelegatingInternalScanner.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/compactions/TestCompactor.java
* (edit)
hbase-examples/src/main/java/org/apache/hadoop/hbase/coprocessor/example/ZooKeeperScanPolicyObserver.java
* (add)
hbase-examples/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
* (edit) hbase-examples/pom.xml
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/compactions/TestStripeCompactionPolicy.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java
> Introduce new example and helper classes to tell CP users how to do filtering
> on scanners
> -
>
> Key: HBASE-18747
> URL: https://issues.apache.org/jira/browse/HBASE-18747
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18747-v1.patch, HBASE-18747.patch
>
>
> Finally we decided that CP users should not have the ability to create
> {{StoreScanner}} or {{StoreFileScanner}}, so it is impossible for them to
> filter out some cells when flush or compaction by simply provide a filter
> when constructing {{StoreScanner}}.
> But I think filtering out some cells is a very important usage for CP users,
> so we need to provide the ability in another way. Theoretically it can be
> done with wrapping an {{InternalScanner}}, but I think we need to give an
> example, or even some helper classes to help CP users.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18355) Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614
[ https://issues.apache.org/jira/browse/HBASE-18355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204479#comment-16204479 ] Hudson commented on HBASE-18355: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3883 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3883/]) HBASE-18355 Enable export snapshot tests that were disabled by Proc-V2 (hsun: rev 9e7156ae68fad16d37fcf77fb8fc5819c1c0037e) * (edit) hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/snapshot/TestExportSnapshot.java * (edit) hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/snapshot/TestSecureExportSnapshot.java * (edit) hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/snapshot/TestMobExportSnapshot.java * (edit) hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/snapshot/TestMobSecureExportSnapshot.java * (edit) hbase-mapreduce/pom.xml > Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614 > > > Key: HBASE-18355 > URL: https://issues.apache.org/jira/browse/HBASE-18355 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0.0-alpha-1 >Reporter: Stephen Yuan Jiang >Assignee: huaxiang sun > Fix For: 3.0.0, 2.0.0-alpha-4 > > Attachments: HBASE-18355-master_v001.patch, > HBASE-18355-master_v002.patch > > > The Proc-V2 AM in HBASE-14614 disabled the following tests: > - Disabled TestExportSnapshot Hangs. > - Disabled TestSecureExportSnapshot > - Disabled TestMobSecureExportSnapshot and TestMobExportSnapshot > This JIRA tracks the work to enable them. If MOB requires more work, we > could split to 2 tickets. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19008) Add missing equals or hashCode method(s) to stock Filter implementations
Ted Yu created HBASE-19008:
--
Summary: Add missing equals or hashCode method(s) to stock Filter
implementations
Key: HBASE-19008
URL: https://issues.apache.org/jira/browse/HBASE-19008
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
In HBASE-15410, [~mdrob] reminded me that Filter implementations may not write
{{equals}} or {{hashCode}} method(s).
This issue is to add missing {{equals}} or {{hashCode}} method(s) to stock
Filter implementations such as KeyOnlyFilter.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15410: --- Fix Version/s: (was: 2.0.0-alpha-3) 2.0.0-alpha-4 > Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList > return SEEK_NEXT_USING_HINT > --- > > Key: HBASE-15410 > URL: https://issues.apache.org/jira/browse/HBASE-15410 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Labels: filter, perfomance > Fix For: 2.0.0-alpha-4, HBASE-18410 > > Attachments: 15410-wip.patch, 15410.branch-1.patch, 15410.v1.patch, > 15410.v2.patch, 15410.v3.patch, 15410.v4.patch > > > As Preston mentioned in the comment in HBASE-15243: > https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557 > An optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek > to the highest hint (Any previous/lower row won't be accepted by the filter > returning that seek). > This JIRA is to explore this potential optimization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14093) deduplicate copies of bootstrap files
[
https://issues.apache.org/jira/browse/HBASE-14093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204463#comment-16204463
]
Hadoop QA commented on HBASE-14093:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 17m
26s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
5s{color} | {color:blue} Shelldocs was not available. {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
36s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
57s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 3m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
4s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m
29s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
18s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 5m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 3m
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
4s{color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
13s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
15s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
35m 5s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}174m
17s{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}270m 45s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-14093 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12892173/HBASE-14093.master.004.patch
|
| Optional Tests | asflicense shadedjars shellcheck shelldocs javac
javadoc unit xml compile |
| uname | Linux a6a4634584ba 3.13.0-116-generic #163-Ubuntu SMP Fri Mar 31
14:13:22 UTC 2017 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 / a6c9d37 |
| Default Java | 1.8.0_144 |
| shellcheck | v0.4.6 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9114/testReport/ |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9114/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
[jira] [Updated] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15410: --- Resolution: Fixed Fix Version/s: (was: 1.5.0) Status: Resolved (was: Patch Available) Thanks all for the reviews. > Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList > return SEEK_NEXT_USING_HINT > --- > > Key: HBASE-15410 > URL: https://issues.apache.org/jira/browse/HBASE-15410 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Labels: filter, perfomance > Fix For: HBASE-18410, 2.0.0-alpha-3 > > Attachments: 15410-wip.patch, 15410.branch-1.patch, 15410.v1.patch, > 15410.v2.patch, 15410.v3.patch, 15410.v4.patch > > > As Preston mentioned in the comment in HBASE-15243: > https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557 > An optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek > to the highest hint (Any previous/lower row won't be accepted by the filter > returning that seek). > This JIRA is to explore this potential optimization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18747) Introduce new example and helper classes to tell CP users how to do filtering on scanners
[
https://issues.apache.org/jira/browse/HBASE-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204428#comment-16204428
]
Hudson commented on HBASE-18747:
FAILURE: Integrated in Jenkins build HBase-2.0 #682 (See
[https://builds.apache.org/job/HBase-2.0/682/])
HBASE-18747 Introduce new example and helper classes to tell CP users
(zhangduo: rev 104595137eec5cac9756eb12ed56759a001ea337)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/KeyValueHeap.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/compactions/TestStripeCompactionPolicy.java
* (add)
hbase-examples/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
* (edit) hbase-examples/pom.xml
* (edit)
hbase-examples/src/main/java/org/apache/hadoop/hbase/coprocessor/example/ZooKeeperScanPolicyObserver.java
* (edit) pom.xml
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/InternalScanner.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/compactions/TestCompactor.java
* (add)
hbase-examples/src/main/java/org/apache/hadoop/hbase/coprocessor/example/DelegatingInternalScanner.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionObserverScannerOpenHook.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionObserverInterface.java
> Introduce new example and helper classes to tell CP users how to do filtering
> on scanners
> -
>
> Key: HBASE-18747
> URL: https://issues.apache.org/jira/browse/HBASE-18747
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18747-v1.patch, HBASE-18747.patch
>
>
> Finally we decided that CP users should not have the ability to create
> {{StoreScanner}} or {{StoreFileScanner}}, so it is impossible for them to
> filter out some cells when flush or compaction by simply provide a filter
> when constructing {{StoreScanner}}.
> But I think filtering out some cells is a very important usage for CP users,
> so we need to provide the ability in another way. Theoretically it can be
> done with wrapping an {{InternalScanner}}, but I think we need to give an
> example, or even some helper classes to help CP users.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204426#comment-16204426 ] Hudson commented on HBASE-15410: FAILURE: Integrated in Jenkins build HBase-2.0 #682 (See [https://builds.apache.org/job/HBase-2.0/682/]) HBASE-15410 Utilize the max seek value when all Filters in MUST_PASS_ALL (tedyu: rev 77bfe05503850a47a6c4e9cdedbf73bb74e9daae) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterList.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java > Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList > return SEEK_NEXT_USING_HINT > --- > > Key: HBASE-15410 > URL: https://issues.apache.org/jira/browse/HBASE-15410 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Labels: filter, perfomance > Fix For: 1.5.0, 2.0.0-alpha-3, HBASE-18410 > > Attachments: 15410-wip.patch, 15410.branch-1.patch, 15410.v1.patch, > 15410.v2.patch, 15410.v3.patch, 15410.v4.patch > > > As Preston mentioned in the comment in HBASE-15243: > https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557 > An optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek > to the highest hint (Any previous/lower row won't be accepted by the filter > returning that seek). > This JIRA is to explore this potential optimization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18355) Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614
[ https://issues.apache.org/jira/browse/HBASE-18355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204427#comment-16204427 ] Hudson commented on HBASE-18355: FAILURE: Integrated in Jenkins build HBase-2.0 #682 (See [https://builds.apache.org/job/HBase-2.0/682/]) HBASE-18355 Enable export snapshot tests that were disabled by Proc-V2 (huaxiangsun: rev 7a25ed6d7c3e6d6b9a6a8a53dd1a419918087e04) * (edit) hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/snapshot/TestMobExportSnapshot.java * (edit) hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/snapshot/TestMobSecureExportSnapshot.java * (edit) hbase-mapreduce/pom.xml * (edit) hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/snapshot/TestExportSnapshot.java * (edit) hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/snapshot/TestSecureExportSnapshot.java > Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614 > > > Key: HBASE-18355 > URL: https://issues.apache.org/jira/browse/HBASE-18355 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0.0-alpha-1 >Reporter: Stephen Yuan Jiang >Assignee: huaxiang sun > Fix For: 3.0.0, 2.0.0-alpha-4 > > Attachments: HBASE-18355-master_v001.patch, > HBASE-18355-master_v002.patch > > > The Proc-V2 AM in HBASE-14614 disabled the following tests: > - Disabled TestExportSnapshot Hangs. > - Disabled TestSecureExportSnapshot > - Disabled TestMobSecureExportSnapshot and TestMobExportSnapshot > This JIRA tracks the work to enable them. If MOB requires more work, we > could split to 2 tickets. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18843) Add DistCp support to incremental backup with bulk loading
[ https://issues.apache.org/jira/browse/HBASE-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204425#comment-16204425 ] Hudson commented on HBASE-18843: FAILURE: Integrated in Jenkins build HBase-2.0 #682 (See [https://builds.apache.org/job/HBase-2.0/682/]) HBASE-18843 Add DistCp support to incremental backup with bulk loading (tedyu: rev a4bc3c6db7bad8832c953d809e5a09c94297860f) * (edit) hbase-backup/src/test/java/org/apache/hadoop/hbase/backup/TestBackupBase.java * (edit) hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/impl/IncrementalTableBackupClient.java * (edit) hbase-backup/src/main/java/org/apache/hadoop/hbase/backup/mapreduce/MapReduceBackupCopyJob.java > Add DistCp support to incremental backup with bulk loading > -- > > Key: HBASE-18843 > URL: https://issues.apache.org/jira/browse/HBASE-18843 > Project: HBase > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18843-v1.patch, HBASE-18843-v2.patch, > HBASE-18843-v4.patch, HBASE-18843-v5.patch, HBASE-18843-v6.patch, > HBASE-18843-v7.patch, HBASE-18843-v8.patch > > > Currently, we copy bulk loaded files to backup one-by-one on a client side > (where backup create runs). This has to be replaced with DistCp copying. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18966) Use non-sync TimeRangeTracker as a replacement for TimeRange in ImmutableSegment
[
https://issues.apache.org/jira/browse/HBASE-18966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204413#comment-16204413
]
Hadoop QA commented on HBASE-18966:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
10s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
24s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
14s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
46s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
20s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
2s{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 {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} checkstyle {color} | {color:green} 0m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
18s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
39m 37s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
21s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 96m
15s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
30s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}161m 7s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18966 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12892159/HBASE-18966.v3.patch |
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 6af684250c1d 3.13.0-117-generic #164-Ubuntu SMP Fri Apr 7
11:05:26 UTC 2017 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 / a6c9d37 |
| Default Java | 1.8.0_144 |
| findbugs |
[jira] [Commented] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204409#comment-16204409 ] Hudson commented on HBASE-15410: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3882 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3882/]) HBASE-15410 Utilize the max seek value when all Filters in MUST_PASS_ALL (tedyu: rev ffdc0e6851e7172bfd3a31a0d78a92fa712ece0e) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterList.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java > Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList > return SEEK_NEXT_USING_HINT > --- > > Key: HBASE-15410 > URL: https://issues.apache.org/jira/browse/HBASE-15410 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Labels: filter, perfomance > Fix For: 1.5.0, 2.0.0-alpha-3, HBASE-18410 > > Attachments: 15410-wip.patch, 15410.branch-1.patch, 15410.v1.patch, > 15410.v2.patch, 15410.v3.patch, 15410.v4.patch > > > As Preston mentioned in the comment in HBASE-15243: > https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557 > An optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek > to the highest hint (Any previous/lower row won't be accepted by the filter > returning that seek). > This JIRA is to explore this potential optimization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18974) Document "Becoming a Committer"
[
https://issues.apache.org/jira/browse/HBASE-18974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204401#comment-16204401
]
Hadoop QA commented on HBASE-18974:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
12s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 10m
23s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
3s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
39m 53s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}152m
12s{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
19s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}215m 17s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18974 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891559/HBASE-18974.patch |
| Optional Tests | asflicense shadedjars javac javadoc unit |
| uname | Linux a415b89040a1 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / ffdc0e6 |
| Default Java | 1.8.0_144 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9112/testReport/ |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9112/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Document "Becoming a Committer"
> ---
>
> Key: HBASE-18974
> URL: https://issues.apache.org/jira/browse/HBASE-18974
> Project: HBase
> Issue Type: Bug
> Components: community, documentation
>Reporter: Mike Drob
>Assignee: Mike Drob
> Attachments: HBASE-18974.patch
>
>
> Based on the mailing list discussion at
> https://lists.apache.org/thread.html/81c633cbe1f6f78421cbdad5b9549643c67803a723a9d86a513264c0@%3Cdev.hbase.apache.org%3E
> it sounds like we should record some of the thoughts for future contributors
> to refer to.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18747) Introduce new example and helper classes to tell CP users how to do filtering on scanners
[
https://issues.apache.org/jira/browse/HBASE-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang updated HBASE-18747:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Release Note: Modify ZooKeeperScanPolicyObserver in hbase-examples to show
how to do filtering in the CP hooks of flush and compaction in hbase-2.0.
Status: Resolved (was: Patch Available)
Pushed to master and branch-2.
Thanks all for reviewing.
> Introduce new example and helper classes to tell CP users how to do filtering
> on scanners
> -
>
> Key: HBASE-18747
> URL: https://issues.apache.org/jira/browse/HBASE-18747
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18747-v1.patch, HBASE-18747.patch
>
>
> Finally we decided that CP users should not have the ability to create
> {{StoreScanner}} or {{StoreFileScanner}}, so it is impossible for them to
> filter out some cells when flush or compaction by simply provide a filter
> when constructing {{StoreScanner}}.
> But I think filtering out some cells is a very important usage for CP users,
> so we need to provide the ability in another way. Theoretically it can be
> done with wrapping an {{InternalScanner}}, but I think we need to give an
> example, or even some helper classes to help CP users.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18747) Introduce new example and helper classes to tell CP users how to do filtering on scanners
[
https://issues.apache.org/jira/browse/HBASE-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204395#comment-16204395
]
Duo Zhang commented on HBASE-18747:
---
Let me commit.
> Introduce new example and helper classes to tell CP users how to do filtering
> on scanners
> -
>
> Key: HBASE-18747
> URL: https://issues.apache.org/jira/browse/HBASE-18747
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18747-v1.patch, HBASE-18747.patch
>
>
> Finally we decided that CP users should not have the ability to create
> {{StoreScanner}} or {{StoreFileScanner}}, so it is impossible for them to
> filter out some cells when flush or compaction by simply provide a filter
> when constructing {{StoreScanner}}.
> But I think filtering out some cells is a very important usage for CP users,
> so we need to provide the ability in another way. Theoretically it can be
> done with wrapping an {{InternalScanner}}, but I think we need to give an
> example, or even some helper classes to help CP users.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18997) Remove the redundant methods in RegionInfo
[
https://issues.apache.org/jira/browse/HBASE-18997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204393#comment-16204393
]
Hadoop QA commented on HBASE-18997:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 18m
22s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 11 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
27s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
50s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
3s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
0s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
20s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
18s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
42m 13s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
44s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}126m 29s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 10m
7s{color} | {color:green} hbase-mapreduce in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
48s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}228m 59s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.master.procedure.TestDisableTableProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestDeleteTableProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestCreateTableProcedure |
| | org.apache.hadoop.hbase.master.TestGetLastFlushedSequenceId |
| | org.apache.hadoop.hbase.master.procedure.TestSafemodeBringsDownMaster |
| | org.apache.hadoop.hbase.master.TestMasterFailover |
| | org.apache.hadoop.hbase.master.balancer.TestStochasticLoadBalancer2 |
| |
[jira] [Commented] (HBASE-13346) Clean up Filter package for post 1.0 s/KeyValue/Cell/g
[
https://issues.apache.org/jira/browse/HBASE-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204389#comment-16204389
]
Hadoop QA commented on HBASE-13346:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 15m
36s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 18 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
3s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 8m
22s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
43s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
25s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
48s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
54m 24s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 7m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
14s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}124m
22s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 13m
0s{color} | {color:green} hbase-mapreduce in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 5m
23s{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
21s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}265m 37s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-13346 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12892126/HBASE-13346.master.007.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 8225bfef515c 3.13.0-119-generic
[jira] [Comment Edited] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204387#comment-16204387 ] Appy edited comment on HBASE-19007 at 10/14/17 12:24 AM: - Am very very happy with this design. But am sad why didn't it strike me doing the big CP cleanup. Probably more fun arriving at it together! was (Author: appy): Am very very happy with this design. But am sad why didn't it strike me when i was doing the big CP cleanup. Probably more fun arriving at it together! > Align Services Interfaces in Master and RegionServer > > > Key: HBASE-19007 > URL: https://issues.apache.org/jira/browse/HBASE-19007 > Project: HBase > Issue Type: Task >Reporter: stack >Priority: Blocker > > HBASE-18183 adds a CoprocessorRegionServerService to give a view on > RegionServiceServices that is safe to expose to Coprocessors. > On the Master-side, MasterServices becomes an Interface for exposing to > Coprocessors. > We need to align the two. > For background, see > https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18978) Align the methods in Table and AsyncTable
[
https://issues.apache.org/jira/browse/HBASE-18978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204383#comment-16204383
]
Peter Somogyi edited comment on HBASE-18978 at 10/14/17 12:24 AM:
--
I'm posting here the same content that I sent out to dev list.
To make it simpler to compare the differences between Table and AsyncTable I
put together a spreadsheet.
https://docs.google.com/spreadsheets/d/15DdDp3Yljlb_Mrd3BQuoyzqnhomJhTM8bHvmEa6t6Jc/edit?usp=sharing
I categorized them into the following groups:
1) RPC timeouts
- Both interfaces have the same functionality, however, in AsyncTable the
TimeUnit can be set for each method.
- The getRpcTimeout is deprecated in Table from version 2.0.0, but it is not
deprecated in AsyncTable.
We can make the RPC timeout handling aligned in the 2 interfaces. My
recommendation is to go with the ones in AsyncTable.
2) Coprocessor
- Methods that are related to Coprocessors are only available in Table.
What is the reason for this?
3) List with xAll operations
- We have the ability to run operation (get, delete, put, batch) in batch mode
using a List input parameter in both interfaces. AsyncTable has additional
methods called xAll(List) (e.g. getAll) where we have the same operations but
the whole operation fails if there are any failures.
- The methods related to {{exists}} differ from the previous operations. To
compare it with {{get}}:
|| Table || AsyncTable ||
| Result get(Get get) | CompletableFuture get(Get get) |
| Result[] get(List gets) | List get(List
gets) |
| - | CompletableFuture getAll(List gets) |
| boolean exists(Get get) | CompletableFuture exists(Get get) |
| boolean[] existsAll(List gets) | List
exists(List gets) |
| - | CompletableFuture existsAll(List gets) |
Should we align these methods?
- Method {{batch}} is also similar to these operations, however, the signature
is different between Table and AsyncTable interfaces. Additionally, Table had a
method {{batchCallback}} which is missing from AsyncTable.
4) Checks
Check and mutate methods are way different. Table has checkAndx methods (some
of them are deprecated), but AsyncTable has an interface called
CheckAndMutateBuilder and these kind of operations are handled through that.
5) Scan
Both interfaces include getScanner methods with the same signature.
Additionally, AsyncTable has {{scan}} and {{scanAll}} methods which are not
part of Table interface.
6) Different return types
There are 2 methods that does the same in the 2 interfaces but have different
return types. The ones in Table return with an array and the ones from
AsyncTable return with a List. HBASE-18912 is a similar issue on Admin
interface. Changing only return type is difficult. Do we need to deal with this
problem?
was (Author: psomogyi):
I'm posting here the same content that I sent out to dev list.
To make it simpler to compare the differences between Table and AsyncTable I
put together a spreadsheet.
https://docs.google.com/spreadsheets/d/15DdDp3Yljlb_Mrd3BQuoyzqnhomJhTM8bHvmEa6t6Jc/edit?usp=sharing
I categorized them into the following groups:
* RPC timeouts
- Both interfaces have the same functionality, however, in AsyncTable the
TimeUnit can be set for each method.
- The getRpcTimeout is deprecated in Table from version 2.0.0, but it is not
deprecated in AsyncTable.
We can make the RPC timeout handling aligned in the 2 interfaces. My
recommendation is to go with the ones in AsyncTable.
* Coprocessor
- Methods that are related to Coprocessors are only available in Table.
What is the reason for this?
* List with xAll operations
- We have the ability to run operation (get, delete, put, batch) in batch mode
using a List input parameter in both interfaces. AsyncTable has additional
methods called xAll(List) (e.g. getAll) where we have the same operations but
the whole operation fails if there are any failures.
- The methods related to {exists} differ from the previous operations. To
compare it with {get}:
Table | AsyncTable
---
Result get(Get get) | CompletableFuture
get(Get get)
Result[] get(List gets) | List
get(List gets)
-|
CompletableFuture getAll(List gets)
---
boolean exists(Get get)| CompletableFuture
exists(Get get)
boolean[] existsAll(List gets) | List
exists(List gets)
-|
CompletableFuture existsAll(List gets)
Should we align
[jira] [Commented] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204387#comment-16204387 ] Appy commented on HBASE-19007: -- Am very very happy with this design. But am sad why didn't it strike me when i was doing the big CP cleanup. Probably more fun arriving at it together! > Align Services Interfaces in Master and RegionServer > > > Key: HBASE-19007 > URL: https://issues.apache.org/jira/browse/HBASE-19007 > Project: HBase > Issue Type: Task >Reporter: stack >Priority: Blocker > > HBASE-18183 adds a CoprocessorRegionServerService to give a view on > RegionServiceServices that is safe to expose to Coprocessors. > On the Master-side, MasterServices becomes an Interface for exposing to > Coprocessors. > We need to align the two. > For background, see > https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18978) Align the methods in Table and AsyncTable
[
https://issues.apache.org/jira/browse/HBASE-18978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204383#comment-16204383
]
Peter Somogyi commented on HBASE-18978:
---
I'm posting here the same content that I sent out to dev list.
To make it simpler to compare the differences between Table and AsyncTable I
put together a spreadsheet.
https://docs.google.com/spreadsheets/d/15DdDp3Yljlb_Mrd3BQuoyzqnhomJhTM8bHvmEa6t6Jc/edit?usp=sharing
I categorized them into the following groups:
* RPC timeouts
- Both interfaces have the same functionality, however, in AsyncTable the
TimeUnit can be set for each method.
- The getRpcTimeout is deprecated in Table from version 2.0.0, but it is not
deprecated in AsyncTable.
We can make the RPC timeout handling aligned in the 2 interfaces. My
recommendation is to go with the ones in AsyncTable.
* Coprocessor
- Methods that are related to Coprocessors are only available in Table.
What is the reason for this?
* List with xAll operations
- We have the ability to run operation (get, delete, put, batch) in batch mode
using a List input parameter in both interfaces. AsyncTable has additional
methods called xAll(List) (e.g. getAll) where we have the same operations but
the whole operation fails if there are any failures.
- The methods related to {exists} differ from the previous operations. To
compare it with {get}:
Table | AsyncTable
---
Result get(Get get) | CompletableFuture
get(Get get)
Result[] get(List gets) | List
get(List gets)
-|
CompletableFuture getAll(List gets)
---
boolean exists(Get get)| CompletableFuture
exists(Get get)
boolean[] existsAll(List gets) | List
exists(List gets)
-|
CompletableFuture existsAll(List gets)
Should we align these methods?
- Method {batch} is also similar to these operations, however, the signature is
different between Table and AsyncTable interfaces. Additionally, Table had a
method {batchCallback} which is missing from AsyncTable.
* Checks
Check and mutate methods are way different. Table has checkAndx methods (some
of them are deprecated), but AsyncTable has an interface called
CheckAndMutateBuilder and these kind of operations are handled through that.
* Scan
Both interfaces include getScanner methods with the same signature.
Additionally, AsyncTable has {scan} and {scanAll} methods which are not part of
Table interface.
* Different return types
There are 2 methods that does the same in the 2 interfaces but have different
return types. The ones in Table return with an array and the ones from
AsyncTable return with a List. HBASE-18912 is a similar issue on Admin
interface. Changing only return type is difficult. Do we need to deal with this
problem?
> Align the methods in Table and AsyncTable
> -
>
> Key: HBASE-18978
> URL: https://issues.apache.org/jira/browse/HBASE-18978
> Project: HBase
> Issue Type: Task
> Components: asyncclient, Client
>Reporter: Duo Zhang
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204381#comment-16204381 ] stack edited comment on HBASE-19007 at 10/14/17 12:11 AM: -- Chatted w/ [~appy]. We came up w/ this h3. Proposal * Undo exposing RegionServerServices and MasterServices to coprocessors. * Only expose Server to Coprocessors so they can do getServerName, getConfiguration, etc. (The amended HBASE-12260 Server, the one that has a few extra methods and the IA.LP annotation added). * Amend MasterCoprocessorEnvironment and RegionServerCoprocessorEnvironment adding to these classes any methods/facility we want to expose to Coprocessors. For example, we'd have the MasterCorprocessorEnvironment implement ServerListener so a CP could register itself on the Master-side to listen to the coming and going of Servers or we'd add to MasterCPE the isActiveMaster method. CPs would do env#isActiveMaster() instead of env#getMasterServices().isActiveMaster(). Benefits: * MS and RSS can return to their original intent as pure Interfaces useful in test and giving Managers and Services a subset of total Master function (though they are overburdened still and in need of cleanup). * What we provide CPs is untangled from Server and its subclasses and moved to the proper location, the 'environment' we supply CPs when they run. Downsides:? [~anoop.hbase] You good w/ this? I can work on a patch for Master-side to show what it would look like. was (Author: stack): Chatted w/ [~appy]. We came up w/ this proposal: * Undo exposing RegionServerServices and MasterServices to coprocessors. * Only expose Server to Coprocessors so they can do getServerName, getConfiguration, etc. (The amended HBASE-12260 Server, the one that has a few extra methods and the IA.LP annotation added). * Amend MasterCoprocessorEnvironment and RegionServerCoprocessorEnvironment adding to these classes any methods/facility we want to expose to Coprocessors. For example, we'd have the MasterCorprocessorEnvironment implement ServerListener so a CP could register itself on the Master-side to listen to the coming and going of Servers or we'd add to MasterCPE the isActiveMaster method. CPs would do env#isActiveMaster() instead of env#getMasterServices().isActiveMaster(). Benefits: * MS and RSS can return to their original intent as pure Interfaces useful in test and giving Managers and Services a subset of total Master function (though they are overburdened still and in need of cleanup). * What we provide CPs is untangled from Server and its subclasses and moved to the proper location, the 'environment' we supply CPs when they run. Downsides:? [~anoop.hbase] You good w/ this? I can work on a patch for Master-side to show what it would look like. > Align Services Interfaces in Master and RegionServer > > > Key: HBASE-19007 > URL: https://issues.apache.org/jira/browse/HBASE-19007 > Project: HBase > Issue Type: Task >Reporter: stack >Priority: Blocker > > HBASE-18183 adds a CoprocessorRegionServerService to give a view on > RegionServiceServices that is safe to expose to Coprocessors. > On the Master-side, MasterServices becomes an Interface for exposing to > Coprocessors. > We need to align the two. > For background, see > https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204381#comment-16204381 ] stack edited comment on HBASE-19007 at 10/14/17 12:11 AM: -- Chatted w/ [~appy]. We came up w/ this h2. Proposal * Undo exposing RegionServerServices and MasterServices to coprocessors. * Only expose Server to Coprocessors so they can do getServerName, getConfiguration, etc. (The amended HBASE-12260 Server, the one that has a few extra methods and the IA.LP annotation added). * Amend MasterCoprocessorEnvironment and RegionServerCoprocessorEnvironment adding to these classes any methods/facility we want to expose to Coprocessors. For example, we'd have the MasterCorprocessorEnvironment implement ServerListener so a CP could register itself on the Master-side to listen to the coming and going of Servers or we'd add to MasterCPE the isActiveMaster method. CPs would do env#isActiveMaster() instead of env#getMasterServices().isActiveMaster(). Benefits: * MS and RSS can return to their original intent as pure Interfaces useful in test and giving Managers and Services a subset of total Master function (though they are overburdened still and in need of cleanup). * What we provide CPs is untangled from Server and its subclasses and moved to the proper location, the 'environment' we supply CPs when they run. Downsides:? [~anoop.hbase] You good w/ this? I can work on a patch for Master-side to show what it would look like. was (Author: stack): Chatted w/ [~appy]. We came up w/ this h3. Proposal * Undo exposing RegionServerServices and MasterServices to coprocessors. * Only expose Server to Coprocessors so they can do getServerName, getConfiguration, etc. (The amended HBASE-12260 Server, the one that has a few extra methods and the IA.LP annotation added). * Amend MasterCoprocessorEnvironment and RegionServerCoprocessorEnvironment adding to these classes any methods/facility we want to expose to Coprocessors. For example, we'd have the MasterCorprocessorEnvironment implement ServerListener so a CP could register itself on the Master-side to listen to the coming and going of Servers or we'd add to MasterCPE the isActiveMaster method. CPs would do env#isActiveMaster() instead of env#getMasterServices().isActiveMaster(). Benefits: * MS and RSS can return to their original intent as pure Interfaces useful in test and giving Managers and Services a subset of total Master function (though they are overburdened still and in need of cleanup). * What we provide CPs is untangled from Server and its subclasses and moved to the proper location, the 'environment' we supply CPs when they run. Downsides:? [~anoop.hbase] You good w/ this? I can work on a patch for Master-side to show what it would look like. > Align Services Interfaces in Master and RegionServer > > > Key: HBASE-19007 > URL: https://issues.apache.org/jira/browse/HBASE-19007 > Project: HBase > Issue Type: Task >Reporter: stack >Priority: Blocker > > HBASE-18183 adds a CoprocessorRegionServerService to give a view on > RegionServiceServices that is safe to expose to Coprocessors. > On the Master-side, MasterServices becomes an Interface for exposing to > Coprocessors. > We need to align the two. > For background, see > https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204381#comment-16204381 ] stack commented on HBASE-19007: --- Chatted w/ [~appy]. We came up w/ this proposal: * Undo exposing RegionServerServices and MasterServices to coprocessors. * Only expose Server to Coprocessors so they can do getServerName, getConfiguration, etc. (The amended HBASE-12260 Server, the one that has a few extra methods and the IA.LP annotation added). * Amend MasterCoprocessorEnvironment and RegionServerCoprocessorEnvironment adding to these classes any methods/facility we want to expose to Coprocessors. For example, we'd have the MasterCorprocessorEnvironment implement ServerListener so a CP could register itself on the Master-side to listen to the coming and going of Servers or we'd add to MasterCPE the isActiveMaster method. CPs would do env#isActiveMaster() instead of env#getMasterServices().isActiveMaster(). Benefits: * MS and RSS can return to their original intent as pure Interfaces useful in test and giving Managers and Services a subset of total Master function (though they are overburdened still and in need of cleanup). * What we provide CPs is untangled from Server and its subclasses and moved to the proper location, the 'environment' we supply CPs when they run. Downsides:? [~anoop.hbase] You good w/ this? I can work on a patch for Master-side to show what it would look like. > Align Services Interfaces in Master and RegionServer > > > Key: HBASE-19007 > URL: https://issues.apache.org/jira/browse/HBASE-19007 > Project: HBase > Issue Type: Task >Reporter: stack >Priority: Blocker > > HBASE-18183 adds a CoprocessorRegionServerService to give a view on > RegionServiceServices that is safe to expose to Coprocessors. > On the Master-side, MasterServices becomes an Interface for exposing to > Coprocessors. > We need to align the two. > For background, see > https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[
https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204355#comment-16204355
]
stack commented on HBASE-19007:
---
One thought is to remove CoprocessorRegionServerServices and instead just
expose Server.
The CorprocessorRegionServerServices looks like this:
{code}
public interface CoprocessorRegionServerServices extends ImmutableOnlineRegions
{
boolean isStopping();
FileSystem getFileSystem();
Set getOnlineTables();
Connection getConnection();
ServerName getServerName();
{code}
HBASE-12260 changes Server to look like this:
{code}
// This Interface shines through MasterServices and RegionServerServices. They
subclass it.
// Be careful what you add here. Make sure it ok for CPs to have access else
add elsewhere.
@InterfaceAudience.LimitedPrivate(HBaseInterfaceAudience.COPROC)
public interface Server extends Abortable, Stoppable {
Configuration getConfiguration();
Connection getConnection();
ServerName getServerName();
ChoreService getChoreService();
ZooKeeperWatcher getZooKeeper();
}
{code}
i.e. Server is now annotated as IA.LP.
Server has getZooKeeper and getChoreService. We could let CPs have access to
these items. CPRSS has isStopping, getFileSystem, and getOnlineTables. I don't
think we should expose getFileSystem to CPs. Only the processes should be
modifying FS. isStoppping (isAborting, etc -- the read-only methods) can be
moved to Server. getOnlineTables is weird. For Quota only. Lets fix Quota and
not expose it here.
So, it looks like the HBASE-12260 could be used in place of CPRSS. On the RS
side, we could have Server for CPs and RSS for everywhere else.
Regards MasterService in HBASE-12260, here is what it looks like currently:
{code}
boolean isServerCrashProcessingEnabled();
boolean isActiveMaster();
boolean isInitialized();
boolean isInMaintenanceMode();
boolean isStopping();
boolean isSplitOrMergeEnabled(MasterSwitchType switchType);
public String getRegionServerVersion(final ServerName sn);
String getClientIdAuditPrefix();
void registerListener(final ServerListener listener);
boolean unregisterListener(final ServerListener listener);
{code}
No CP cares about isServerCrashPrcoessingEnabled. They might care about
isInitialized though doubt it as long as we ensure CP is only up at end of
initialization. isActiveMaster is not a CP concern. isMaintenanceMode neither.
isStopping would be in Server. isSplitOrMergeEnabled is something they can ask
of Admin Interface. getRegionServerVersion should be in Server as getVersion.
getClientIdAuditPrefix and the registerListener/unregister could be put into a
small Master mix-in Interface.
Proposal is that on the RS-side, rather than CPRSS we give CPs a
slightly-amended Server Interface. On Master side we hand-in a
MasterCoprocessorServices which would be a Server + ServerLIstener Interface
(and perhaps one or two other methods).
Perhaps better is we change *CoprocessorHost so they both have a getServer
method to return Server and then a getServices to return a Master/RegionServer
specific Interface of a minimal items.
> Align Services Interfaces in Master and RegionServer
>
>
> Key: HBASE-19007
> URL: https://issues.apache.org/jira/browse/HBASE-19007
> Project: HBase
> Issue Type: Task
>Reporter: stack
>Priority: Blocker
>
> HBASE-18183 adds a CoprocessorRegionServerService to give a view on
> RegionServiceServices that is safe to expose to Coprocessors.
> On the Master-side, MasterServices becomes an Interface for exposing to
> Coprocessors.
> We need to align the two.
> For background, see
> https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18233) We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock
[
https://issues.apache.org/jira/browse/HBASE-18233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204335#comment-16204335
]
Hadoop QA commented on HBASE-18233:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 18m
46s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
38s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
32s{color} | {color:green} branch-1.2 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
34s{color} | {color:green} branch-1.2 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
59s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
24s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
52s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
57s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} branch-1.2 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} branch-1.2 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
34s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
34s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
17s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 41s{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.6.4 2.6.5 2.7.1 2.7.2 2.7.3.
{color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
24s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}240m 14s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
59s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}304m 0s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.mapreduce.TestMultiTableSnapshotInputFormat
|
| Timed out junit tests |
org.apache.hadoop.hbase.replication.TestReplicationKillSlaveRS |
| | org.apache.hadoop.hbase.regionserver.TestCorruptedRegionStoreFile |
| |
[jira] [Commented] (HBASE-14093) deduplicate copies of bootstrap files
[ https://issues.apache.org/jira/browse/HBASE-14093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204326#comment-16204326 ] Tamas Penzes commented on HBASE-14093: -- [~mdrob] tab.js fixed maven hack removed (I've checked it, it's not needed any more) bootstrap updated to latest I haven't moved the logic of downloading and extracting bootstrap and jquery to hbase-assembly, because this way we have a simple, easy to test web module, which doesn't depend on anything. The files fit into this project, and hbase-assembly can stay consistent. Opinion? > deduplicate copies of bootstrap files > - > > Key: HBASE-14093 > URL: https://issues.apache.org/jira/browse/HBASE-14093 > Project: HBase > Issue Type: Improvement > Components: build >Reporter: Sean Busbey >Assignee: Tamas Penzes > Labels: beginner > Fix For: 2.0.0 > > Attachments: HBASE-14093.master.001.patch, > HBASE-14093.master.002.patch, HBASE-14093.master.002.patch, > HBASE-14093.master.003.patch, HBASE-14093.master.003.patch, > HBASE-14093.master.004.patch, patch-shadedjars.txt > > > right now we have a couple of different copies of the bootstrap js and css > files. It'll be easier to maintain them later if we can centralize. > Move them to a common location and use maven to populate them as needed in > various component build directories. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-14093) deduplicate copies of bootstrap files
[ https://issues.apache.org/jira/browse/HBASE-14093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated HBASE-14093: - Status: Patch Available (was: Open) > deduplicate copies of bootstrap files > - > > Key: HBASE-14093 > URL: https://issues.apache.org/jira/browse/HBASE-14093 > Project: HBase > Issue Type: Improvement > Components: build >Reporter: Sean Busbey >Assignee: Tamas Penzes > Labels: beginner > Fix For: 2.0.0 > > Attachments: HBASE-14093.master.001.patch, > HBASE-14093.master.002.patch, HBASE-14093.master.002.patch, > HBASE-14093.master.003.patch, HBASE-14093.master.003.patch, > HBASE-14093.master.004.patch, patch-shadedjars.txt > > > right now we have a couple of different copies of the bootstrap js and css > files. It'll be easier to maintain them later if we can centralize. > Move them to a common location and use maven to populate them as needed in > various component build directories. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-14093) deduplicate copies of bootstrap files
[ https://issues.apache.org/jira/browse/HBASE-14093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated HBASE-14093: - Status: Open (was: Patch Available) > deduplicate copies of bootstrap files > - > > Key: HBASE-14093 > URL: https://issues.apache.org/jira/browse/HBASE-14093 > Project: HBase > Issue Type: Improvement > Components: build >Reporter: Sean Busbey >Assignee: Tamas Penzes > Labels: beginner > Fix For: 2.0.0 > > Attachments: HBASE-14093.master.001.patch, > HBASE-14093.master.002.patch, HBASE-14093.master.002.patch, > HBASE-14093.master.003.patch, HBASE-14093.master.003.patch, > HBASE-14093.master.004.patch, patch-shadedjars.txt > > > right now we have a couple of different copies of the bootstrap js and css > files. It'll be easier to maintain them later if we can centralize. > Move them to a common location and use maven to populate them as needed in > various component build directories. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-14093) deduplicate copies of bootstrap files
[ https://issues.apache.org/jira/browse/HBASE-14093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated HBASE-14093: - Attachment: HBASE-14093.master.004.patch > deduplicate copies of bootstrap files > - > > Key: HBASE-14093 > URL: https://issues.apache.org/jira/browse/HBASE-14093 > Project: HBase > Issue Type: Improvement > Components: build >Reporter: Sean Busbey >Assignee: Tamas Penzes > Labels: beginner > Fix For: 2.0.0 > > Attachments: HBASE-14093.master.001.patch, > HBASE-14093.master.002.patch, HBASE-14093.master.002.patch, > HBASE-14093.master.003.patch, HBASE-14093.master.003.patch, > HBASE-14093.master.004.patch, patch-shadedjars.txt > > > right now we have a couple of different copies of the bootstrap js and css > files. It'll be easier to maintain them later if we can centralize. > Move them to a common location and use maven to populate them as needed in > various component build directories. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18355) Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614
[ https://issues.apache.org/jira/browse/HBASE-18355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huaxiang sun updated HBASE-18355: - Resolution: Fixed Fix Version/s: 2.0.0-alpha-4 3.0.0 Status: Resolved (was: Patch Available) Fix pushed to master and branch-2. > Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614 > > > Key: HBASE-18355 > URL: https://issues.apache.org/jira/browse/HBASE-18355 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0.0-alpha-1 >Reporter: Stephen Yuan Jiang >Assignee: huaxiang sun > Fix For: 3.0.0, 2.0.0-alpha-4 > > Attachments: HBASE-18355-master_v001.patch, > HBASE-18355-master_v002.patch > > > The Proc-V2 AM in HBASE-14614 disabled the following tests: > - Disabled TestExportSnapshot Hangs. > - Disabled TestSecureExportSnapshot > - Disabled TestMobSecureExportSnapshot and TestMobExportSnapshot > This JIRA tracks the work to enable them. If MOB requires more work, we > could split to 2 tickets. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19007: -- Description: HBASE-18183 adds a CoprocessorRegionServerService to give a view on RegionServiceServices that is safe to expose to Coprocessors. On the Master-side, MasterServices becomes an Interface for exposing to Coprocessors. We need to align the two. For background, see https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820 was: HBASE-18183 adds a CoprocessorRegionServerService to give a view on RegionServiceServices that is safe to expose to Coprocessors. On the Master-side, MasterServices becomes an Interface for exposing to Coprocessors. We need to align the two. > Align Services Interfaces in Master and RegionServer > > > Key: HBASE-19007 > URL: https://issues.apache.org/jira/browse/HBASE-19007 > Project: HBase > Issue Type: Task >Reporter: stack >Priority: Blocker > > HBASE-18183 adds a CoprocessorRegionServerService to give a view on > RegionServiceServices that is safe to expose to Coprocessors. > On the Master-side, MasterServices becomes an Interface for exposing to > Coprocessors. > We need to align the two. > For background, see > https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-18901) Support build with CMake
[ https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved HBASE-18901. Resolution: Fixed Hadoop Flags: Reviewed Thanks for the monumental effort here, [~phrocker]! > Support build with CMake > > > Key: HBASE-18901 > URL: https://issues.apache.org/jira/browse/HBASE-18901 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: marco polo > Labels: C++ > Fix For: HBASE-14850 > > Attachments: HBASE-18901.v1.HBASE-14850.patch, > HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch, > HBASE-18901.v4.HBASE-14850.patch, HBASE-18901.v5.HBASE-14850.patch > > > I've co-opted some help from folks in trying to support CMake as the build > tool instead of Buck. > They have something working, but need to consolidate the patch. Filing an > issue for them to put a patch on. > FYI [~enis], [~tedyu] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18901) Support build with CMake
[ https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204297#comment-16204297 ] Josh Elser commented on HBASE-18901: Awesome. Thanks for the review. Let me get this committed and I'll spin off some other JIRA issues to capture the follow-on's. > Support build with CMake > > > Key: HBASE-18901 > URL: https://issues.apache.org/jira/browse/HBASE-18901 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: marco polo > Labels: C++ > Fix For: HBASE-14850 > > Attachments: HBASE-18901.v1.HBASE-14850.patch, > HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch, > HBASE-18901.v4.HBASE-14850.patch, HBASE-18901.v5.HBASE-14850.patch > > > I've co-opted some help from folks in trying to support CMake as the build > tool instead of Buck. > They have something working, but need to consolidate the patch. Filing an > issue for them to put a patch on. > FYI [~enis], [~tedyu] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204292#comment-16204292 ] stack commented on HBASE-12260: --- I filed HBASE-19007 for figuring this out. > MasterServices needs a short-back-and-sides; pare-back exposure of internals > and IA.Private classes > --- > > Key: HBASE-12260 > URL: https://issues.apache.org/jira/browse/HBASE-12260 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: ryan rawson >Assignee: stack >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-12260.master.001.patch, > HBASE-12260.master.002.patch, HBASE-12260.master.003.patch, > HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, > HBASE-12260.master.006.patch, HBASE-12260.master.007.patch, > HBASE-12260.master.008.patch, HBASE-12260.master.009.patch, > HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, > HBASE-12260.master.011.patch, HBASE-12260.master.012.patch, > HBASE-12260.master.013.patch, HBASE-12260.master.014.patch > > > A major issue with MasterServices is the MasterCoprocessorEnvironment exposes > this class even though MasterServices is tagged with > @InterfaceAudience.Private > This means that the entire internals of the HMaster is essentially part of > the coprocessor API. Many of the classes returned by the MasterServices API > are highly internal, extremely powerful, and subject to constant change. > Perhaps a new API to replace MasterServices that is use-case focused, and > justified based on real world co-processors would suit things better. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18601) Update Htrace to 4.2
[
https://issues.apache.org/jira/browse/HBASE-18601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204287#comment-16204287
]
Hadoop QA commented on HBASE-18601:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
14s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 7 new or modified test
files. {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} 3m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
19s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 5m
47s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
41s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-testing-util . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 11m
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 6m
24s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
13s{color} | {color:red} hbase-rest in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
33s{color} | {color:red} hbase-spark in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 5m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} rubocop {color} | {color:green} 0m
3s{color} | {color:green} There were no new rubocop issues. {color} |
| {color:green}+1{color} | {color:green} ruby-lint {color} | {color:green} 0m
0s{color} | {color:green} There were no new ruby-lint issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
26s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
7s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
37m 29s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-testing-util . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 14m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 6m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
26s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
30s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} |
[jira] [Created] (HBASE-19007) Align Services Interfaces in Master and RegionServer
stack created HBASE-19007: - Summary: Align Services Interfaces in Master and RegionServer Key: HBASE-19007 URL: https://issues.apache.org/jira/browse/HBASE-19007 Project: HBase Issue Type: Task Reporter: stack Priority: Blocker HBASE-18183 adds a CoprocessorRegionServerService to give a view on RegionServiceServices that is safe to expose to Coprocessors. On the Master-side, MasterServices becomes an Interface for exposing to Coprocessors. We need to align the two. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18901) Support build with CMake
[
https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204275#comment-16204275
]
Enis Soztutar commented on HBASE-18901:
---
I was able to test v5 successfully. The build goes through, and tests are
running with {{make test}} in the docker env.
Great work, +1 for the patch, but we can do these follow ups:
- target executables (xxx-test and load-client, etc) should be generated
under build/ or CMakeFiles/.
- Make test is hanging at async-batch-rpc-retrying-test for me:
{code}
root@securecluster:/usr/src/hbase/hbase-native-client# make test
Running tests...
Test project /usr/src/hbase/hbase-native-client
Start 1: append-test
1/33 Test #1: append-test .. Passed0.00 sec
Start 2: async-batch-rpc-retrying-test
{code}
- Possibly break up the test files under src/test/ to be {{src/test/client}},
{{src/test/connection}}, etc.
- Hook up cmake with the general mvn build by providing a pom.xml in the
module. calling mvn compile or test with -Pnative should kick in the native
build with cmake. See Hadoop's integration for an example.
> Support build with CMake
>
>
> Key: HBASE-18901
> URL: https://issues.apache.org/jira/browse/HBASE-18901
> Project: HBase
> Issue Type: Sub-task
>Reporter: Josh Elser
>Assignee: marco polo
> Labels: C++
> Fix For: HBASE-14850
>
> Attachments: HBASE-18901.v1.HBASE-14850.patch,
> HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch,
> HBASE-18901.v4.HBASE-14850.patch, HBASE-18901.v5.HBASE-14850.patch
>
>
> I've co-opted some help from folks in trying to support CMake as the build
> tool instead of Buck.
> They have something working, but need to consolidate the patch. Filing an
> issue for them to put a patch on.
> FYI [~enis], [~tedyu]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[
https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204270#comment-16204270
]
Hadoop QA commented on HBASE-15410:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
56s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
52s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
40s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
42m 25s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
51s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}101m
52s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}173m 43s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-15410 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12892122/15410.v4.patch |
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux e1ccff1888be 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 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 / f6a8a76 |
| Default Java | 1.8.0_144 |
| findbugs |
[jira] [Commented] (HBASE-19006) Fix TestIncrementalBackupWithBulkLoad under hadoop3
[ https://issues.apache.org/jira/browse/HBASE-19006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204268#comment-16204268 ] Ted Yu commented on HBASE-19006: You had two versions of code w.r.t. CopyListingFileStatus You can try the first version to see if there is still similar error in DictCp output. If not, then it is matter of getting refactoring right. > Fix TestIncrementalBackupWithBulkLoad under hadoop3 > --- > > Key: HBASE-19006 > URL: https://issues.apache.org/jira/browse/HBASE-19006 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Critical > Fix For: 2.0.0-beta-2 > > Attachments: > org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad-output.txt.gz > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18843) Add DistCp support to incremental backup with bulk loading
[ https://issues.apache.org/jira/browse/HBASE-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-18843: --- Resolution: Fixed Status: Resolved (was: Patch Available) Thanks for the patch, Vlad. Thanks for the review, Josh. > Add DistCp support to incremental backup with bulk loading > -- > > Key: HBASE-18843 > URL: https://issues.apache.org/jira/browse/HBASE-18843 > Project: HBase > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18843-v1.patch, HBASE-18843-v2.patch, > HBASE-18843-v4.patch, HBASE-18843-v5.patch, HBASE-18843-v6.patch, > HBASE-18843-v7.patch, HBASE-18843-v8.patch > > > Currently, we copy bulk loaded files to backup one-by-one on a client side > (where backup create runs). This has to be replaced with DistCp copying. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19006) Fix TestIncrementalBackupWithBulkLoad under hadoop3
[ https://issues.apache.org/jira/browse/HBASE-19006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204253#comment-16204253 ] Ted Yu commented on HBASE-19006: Since the first exception was related to CopyListingFileStatus, I suggest taking a closer look at the CopyListingFileStatus related code from hbase side. Maybe capture the sequence file before submitting the Job for analysis. > Fix TestIncrementalBackupWithBulkLoad under hadoop3 > --- > > Key: HBASE-19006 > URL: https://issues.apache.org/jira/browse/HBASE-19006 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Critical > Fix For: 2.0.0-beta-2 > > Attachments: > org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad-output.txt.gz > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18843) Add DistCp support to incremental backup with bulk loading
[
https://issues.apache.org/jira/browse/HBASE-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204249#comment-16204249
]
Hadoop QA commented on HBASE-18843:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
10s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
1s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
37s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
54s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
46m 52s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 9m
47s{color} | {color:green} hbase-backup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
11s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 69m 48s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18843 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12892131/HBASE-18843-v8.patch |
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 861daeeace94 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / ffdc0e6 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9110/testReport/ |
| modules | C: hbase-backup U: hbase-backup |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9110/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Add DistCp support to incremental backup with bulk loading
>
[jira] [Commented] (HBASE-19006) Fix TestIncrementalBackupWithBulkLoad under hadoop3
[
https://issues.apache.org/jira/browse/HBASE-19006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204247#comment-16204247
]
Ted Yu commented on HBASE-19006:
{code}
2017-10-13 13:55:56,703 WARN [Thread-881] mapred.LocalJobRunner$Job(590):
job_local876554327_0004
java.io.IOException: Inconsistent sequence file: current chunk file
org.apache.hadoop.tools.CopyListingFileStatus@e44de415{hdfs://localhost:62602/user/vrodionov/test-data/
6b218856-adc9-4659-ad15-868aa83e6c48/data/ns1/test-1507928111932/95d195f6a91639b50388e50fc8751d69/f/7e45c3c177964f0cb315c8d2456b8b90_SeqId_205_
length = 5100 aclEntries = null, xAttrs = null} doesnt match prior entry
org.apache.hadoop.tools.CopyListingFileStatus@a91b2cdf{hdfs://localhost:62602/user/vrodionov/test-data/6b218856-adc9-4659-ad15-
868aa83e6c48/data/ns1/test-1507928111932/95d195f6a91639b50388e50fc8751d69/f/615e1b7549ff47b68a9d599ae7f6832f_SeqId_205_
length = 5142 aclEntries = null, xAttrs = null}
at
org.apache.hadoop.tools.mapred.CopyCommitter.concatFileChunks(CopyCommitter.java:269)
at
org.apache.hadoop.tools.mapred.CopyCommitter.commitJob(CopyCommitter.java:96)
at org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:567)
...
2017-10-13 13:55:56,830 ERROR [main] tools.DistCp(167): Exception encountered
java.lang.Exception: DistCp job-id: job_local876554327_0004 failed
at
org.apache.hadoop.hbase.backup.mapreduce.MapReduceBackupCopyJob$BackupDistCp.execute(MapReduceBackupCopyJob.java:248)
at org.apache.hadoop.tools.DistCp.run(DistCp.java:153)
at
org.apache.hadoop.hbase.backup.mapreduce.MapReduceBackupCopyJob.copy(MapReduceBackupCopyJob.java:407)
at
org.apache.hadoop.hbase.backup.impl.IncrementalTableBackupClient.incrementalCopyHFiles(IncrementalTableBackupClient.java:300)
{code}
Interesting - the first stack trace was at WARN and second stack trace didn't
reveal cause ...
> Fix TestIncrementalBackupWithBulkLoad under hadoop3
> ---
>
> Key: HBASE-19006
> URL: https://issues.apache.org/jira/browse/HBASE-19006
> Project: HBase
> Issue Type: Bug
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Critical
> Fix For: 2.0.0-beta-2
>
> Attachments:
> org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad-output.txt.gz
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18966) Use non-sync TimeRangeTracker as a replacement for TimeRange in ImmutableSegment
[
https://issues.apache.org/jira/browse/HBASE-18966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18966:
---
Attachment: HBASE-18966.v3.patch
v3
# fix TestCompactingMemStore
# fix TestCompactingToCellFlatMapMemStore
> Use non-sync TimeRangeTracker as a replacement for TimeRange in
> ImmutableSegment
>
>
> Key: HBASE-18966
> URL: https://issues.apache.org/jira/browse/HBASE-18966
> Project: HBase
> Issue Type: Sub-task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18966.v0.patch, HBASE-18966.v1.patch,
> HBASE-18966.v2.patch, HBASE-18966.v2.patch, HBASE-18966.v3.patch
>
>
> The in-memory compaction/merge updates only the {{TimeRangeTracker}} when
> creating new {{ImmutableSegment}}, but the time information used to do time
> filter is the {{TimeRange}} rather than {{TimeRangeTracker}}. It don't cause
> any bugs currently because the {{TimeRange}} is used for store-level ts
> filter only and the default {{TimeRange}} of {{ImmutableSegment}} created by
> in-memory compaction/merge has the maximum ts range.
> The {{TimeRange}} was used to be a snapshot of {{TimeRangeTracker}} for
> avoiding the sync operation happening in {{TimeRangeTracker}}. We can use
> non-sync trt introduced by HBASE-18753 to replace the {{TimeRange}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18966) Use non-sync TimeRangeTracker as a replacement for TimeRange in ImmutableSegment
[
https://issues.apache.org/jira/browse/HBASE-18966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18966:
---
Status: Patch Available (was: Open)
> Use non-sync TimeRangeTracker as a replacement for TimeRange in
> ImmutableSegment
>
>
> Key: HBASE-18966
> URL: https://issues.apache.org/jira/browse/HBASE-18966
> Project: HBase
> Issue Type: Sub-task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18966.v0.patch, HBASE-18966.v1.patch,
> HBASE-18966.v2.patch, HBASE-18966.v2.patch, HBASE-18966.v3.patch
>
>
> The in-memory compaction/merge updates only the {{TimeRangeTracker}} when
> creating new {{ImmutableSegment}}, but the time information used to do time
> filter is the {{TimeRange}} rather than {{TimeRangeTracker}}. It don't cause
> any bugs currently because the {{TimeRange}} is used for store-level ts
> filter only and the default {{TimeRange}} of {{ImmutableSegment}} created by
> in-memory compaction/merge has the maximum ts range.
> The {{TimeRange}} was used to be a snapshot of {{TimeRangeTracker}} for
> avoiding the sync operation happening in {{TimeRangeTracker}}. We can use
> non-sync trt introduced by HBASE-18753 to replace the {{TimeRange}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18966) Use non-sync TimeRangeTracker as a replacement for TimeRange in ImmutableSegment
[
https://issues.apache.org/jira/browse/HBASE-18966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18966:
---
Status: Open (was: Patch Available)
> Use non-sync TimeRangeTracker as a replacement for TimeRange in
> ImmutableSegment
>
>
> Key: HBASE-18966
> URL: https://issues.apache.org/jira/browse/HBASE-18966
> Project: HBase
> Issue Type: Sub-task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18966.v0.patch, HBASE-18966.v1.patch,
> HBASE-18966.v2.patch, HBASE-18966.v2.patch
>
>
> The in-memory compaction/merge updates only the {{TimeRangeTracker}} when
> creating new {{ImmutableSegment}}, but the time information used to do time
> filter is the {{TimeRange}} rather than {{TimeRangeTracker}}. It don't cause
> any bugs currently because the {{TimeRange}} is used for store-level ts
> filter only and the default {{TimeRange}} of {{ImmutableSegment}} created by
> in-memory compaction/merge has the maximum ts range.
> The {{TimeRange}} was used to be a snapshot of {{TimeRangeTracker}} for
> avoiding the sync operation happening in {{TimeRangeTracker}}. We can use
> non-sync trt introduced by HBASE-18753 to replace the {{TimeRange}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18355) Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614
[ https://issues.apache.org/jira/browse/HBASE-18355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204237#comment-16204237 ] huaxiang sun commented on HBASE-18355: -- Thanks [~tedyu] and [~mdrob] for review! I pushed the patch to master and will push it to branch-2. > Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614 > > > Key: HBASE-18355 > URL: https://issues.apache.org/jira/browse/HBASE-18355 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0.0-alpha-1 >Reporter: Stephen Yuan Jiang >Assignee: huaxiang sun > Attachments: HBASE-18355-master_v001.patch, > HBASE-18355-master_v002.patch > > > The Proc-V2 AM in HBASE-14614 disabled the following tests: > - Disabled TestExportSnapshot Hangs. > - Disabled TestSecureExportSnapshot > - Disabled TestMobSecureExportSnapshot and TestMobExportSnapshot > This JIRA tracks the work to enable them. If MOB requires more work, we > could split to 2 tickets. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18624) Added support for clearing BlockCache based on table name
[ https://issues.apache.org/jira/browse/HBASE-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204234#comment-16204234 ] Ted Yu commented on HBASE-18624: Sounds good to me. > Added support for clearing BlockCache based on table name > - > > Key: HBASE-18624 > URL: https://issues.apache.org/jira/browse/HBASE-18624 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0, 1.3.0 >Reporter: Ajay Jadhav >Assignee: Zach York > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-18624.branch-1.001.patch, > HBASE-18624.master.001.patch, HBASE-18624.master.002.patch, > HBASE-18624.master.003.patch > > > Bulk loading the primary HBase cluster triggers a lot of compactions > resulting in archival/ creation > of multiple HFiles. This process will cause a lot of items to become stale in > replica’s BlockCache. > This patch will help users to clear the block cache for a given table by > either using shell or API. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18901) Support build with CMake
[ https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204209#comment-16204209 ] Enis Soztutar commented on HBASE-18901: --- bq. we just need to make sure that we're consistently using the new or old ABI (and also knowing which the libraries on the system we're linking against are using!) Indeed. This is definitely causing problems at link time, if some dependencies are using old versus new. My previous attempts at moving everything to the new ABI failed after spending a full day at it. You need to re-compile every dependency. Glad that you got it working with CMake. Also we can close HBASE-18726 after this. bq. Switched the Docker image off of the folly-specific one to a stock ubuntu16.04 image Cool. Let me try it out. Previous docker base image is impossible to reproduce with the Dockerfile making changes to it very hard. > Support build with CMake > > > Key: HBASE-18901 > URL: https://issues.apache.org/jira/browse/HBASE-18901 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: marco polo > Labels: C++ > Fix For: HBASE-14850 > > Attachments: HBASE-18901.v1.HBASE-14850.patch, > HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch, > HBASE-18901.v4.HBASE-14850.patch, HBASE-18901.v5.HBASE-14850.patch > > > I've co-opted some help from folks in trying to support CMake as the build > tool instead of Buck. > They have something working, but need to consolidate the patch. Filing an > issue for them to put a patch on. > FYI [~enis], [~tedyu] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18999) Put in hbase shell cannot do multiple columns
[
https://issues.apache.org/jira/browse/HBASE-18999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204191#comment-16204191
]
Mike Drob commented on HBASE-18999:
---
Sounds good, [~chia7712]
> Put in hbase shell cannot do multiple columns
> -
>
> Key: HBASE-18999
> URL: https://issues.apache.org/jira/browse/HBASE-18999
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 1.0.0, 2.0.0
>Reporter: Mike Drob
>
> A {{Put}} can carry multiple cells, but doing so in the shell is very
> difficult to construct. We should make this easier.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204189#comment-16204189
]
Hudson commented on HBASE-18505:
FAILURE: Integrated in Jenkins build HBase-1.4 #953 (See
[https://builds.apache.org/job/HBase-1.4/953/])
HBASE-18505 Yetus only run root when all modules changed (mdrob: rev
03bd72c5e3a43ab54bbfeb729e4b09cf4325f4bc)
* (edit) dev-support/hbase-personality.sh
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-18505.actual.patch, HBASE-18505.patch,
> HBASE-18505.v2.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18999) Put in hbase shell cannot do multiple columns
[
https://issues.apache.org/jira/browse/HBASE-18999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204188#comment-16204188
]
Chia-Ping Tsai commented on HBASE-18999:
The {{Delete}} command has similar issue. Our shell is not fully fledged. What
about filing a umbrella jira to revisit the CRUD in shell?
> Put in hbase shell cannot do multiple columns
> -
>
> Key: HBASE-18999
> URL: https://issues.apache.org/jira/browse/HBASE-18999
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 1.0.0, 2.0.0
>Reporter: Mike Drob
>
> A {{Put}} can carry multiple cells, but doing so in the shell is very
> difficult to construct. We should make this easier.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18624) Added support for clearing BlockCache based on table name
[ https://issues.apache.org/jira/browse/HBASE-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204185#comment-16204185 ] Zach York commented on HBASE-18624: --- [~anoop.hbase] [~tedyu] so the consensus is to add an object for the Admin return so that we can maintain BC if we change it? > Added support for clearing BlockCache based on table name > - > > Key: HBASE-18624 > URL: https://issues.apache.org/jira/browse/HBASE-18624 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0, 1.3.0 >Reporter: Ajay Jadhav >Assignee: Zach York > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-18624.branch-1.001.patch, > HBASE-18624.master.001.patch, HBASE-18624.master.002.patch, > HBASE-18624.master.003.patch > > > Bulk loading the primary HBase cluster triggers a lot of compactions > resulting in archival/ creation > of multiple HFiles. This process will cause a lot of items to become stale in > replica’s BlockCache. > This patch will help users to clear the block cache for a given table by > either using shell or API. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204184#comment-16204184
]
Hudson commented on HBASE-18505:
SUCCESS: Integrated in Jenkins build HBase-1.1-JDK7 #1923 (See
[https://builds.apache.org/job/HBase-1.1-JDK7/1923/])
HBASE-18505 Yetus only run root when all modules changed (mdrob: rev
9eeb842e99c5c3b9cf1e1905c08c96a6930b431b)
* (edit) dev-support/hbase-personality.sh
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-18505.actual.patch, HBASE-18505.patch,
> HBASE-18505.v2.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19006) Fix TestIncrementalBackupWithBulkLoad under hadoop3
[ https://issues.apache.org/jira/browse/HBASE-19006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-19006: -- Attachment: org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad-output.txt.gz Attached is the output of a failed test > Fix TestIncrementalBackupWithBulkLoad under hadoop3 > --- > > Key: HBASE-19006 > URL: https://issues.apache.org/jira/browse/HBASE-19006 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Critical > Fix For: 2.0.0-beta-2 > > Attachments: > org.apache.hadoop.hbase.backup.TestIncrementalBackupWithBulkLoad-output.txt.gz > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18901) Support build with CMake
[ https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-18901: --- Attachment: HBASE-18901.v5.HBASE-14850.patch v5 has my +1, but will be running through one more test with a clean docker image, etc * Added a cmake target to invoke bin/copy-version.h * Removed the option to use the old cxx11 ABI (to avoid issues linking against shared objects which are using the new ABI) * Switched the Docker image off of the folly-specific one to a stock ubuntu16.04 image > Support build with CMake > > > Key: HBASE-18901 > URL: https://issues.apache.org/jira/browse/HBASE-18901 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: marco polo > Labels: C++ > Fix For: HBASE-14850 > > Attachments: HBASE-18901.v1.HBASE-14850.patch, > HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch, > HBASE-18901.v4.HBASE-14850.patch, HBASE-18901.v5.HBASE-14850.patch > > > I've co-opted some help from folks in trying to support CMake as the build > tool instead of Buck. > They have something working, but need to consolidate the patch. Filing an > issue for them to put a patch on. > FYI [~enis], [~tedyu] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204172#comment-16204172
]
Hudson commented on HBASE-18505:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3881 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/3881/])
HBASE-18505 Yetus only run root when all modules changed (mdrob: rev
f6a8a76b50f2b67638cf83fb4b89703f5e98dedb)
* (edit) dev-support/hbase-personality.sh
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-18505.actual.patch, HBASE-18505.patch,
> HBASE-18505.v2.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204170#comment-16204170
]
Chia-Ping Tsai commented on HBASE-18824:
bq. the code updates the timestamp to the latest version of what could be Get
(why?)
To delete the latest cell, the cell having delete mark should be set the
timestamp of latest cell.
bq. Do I get it correctly?
Yep, please update the patch. Thanks.
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18998) processor.getRowsToLock() always assumes there is some row being locked
[
https://issues.apache.org/jira/browse/HBASE-18998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204171#comment-16204171
]
Hudson commented on HBASE-18998:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3881 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/3881/])
HBASE-18998 processor.getRowsToLock() always assumes there is some row (tedyu:
rev 6ebba3cf2356be46200592ac3c3eb4b4b0d0e420)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> processor.getRowsToLock() always assumes there is some row being locked
> ---
>
> Key: HBASE-18998
> URL: https://issues.apache.org/jira/browse/HBASE-18998
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: 18998.v1.txt
>
>
> During testing, we observed the following exception:
> {code}
> 2017-10-12 02:52:26,683|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|1/1 DROP TABLE
> testTable;
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|17/10/12 02:52:30 WARN
> ipc.CoprocessorRpcChannel: Call failed on IOException
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|org.apache.hadoop.hbase.DoNotRetryIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException: TESTTABLE: null
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:93)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1671)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:14347)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7849)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1980)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1962)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32389)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2150)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:187)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:167)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|Caused by:
> java.util.NoSuchElementException
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> java.util.Collections$EmptyIterator.next(Collections.java:4189)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.processRowsWithLocks(HRegion.java:7137)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.mutateRowsWithLocks(HRegion.java:6980)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.mutateRowsWithLocks(MetaDataEndpointImpl.java:1966)
> 2017-10-12 02:52:30,323|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
>
[jira] [Commented] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204168#comment-16204168
]
Hudson commented on HBASE-18505:
SUCCESS: Integrated in Jenkins build HBase-1.1-JDK8 #2007 (See
[https://builds.apache.org/job/HBase-1.1-JDK8/2007/])
HBASE-18505 Yetus only run root when all modules changed (mdrob: rev
9eeb842e99c5c3b9cf1e1905c08c96a6930b431b)
* (edit) dev-support/hbase-personality.sh
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-18505.actual.patch, HBASE-18505.patch,
> HBASE-18505.v2.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204167#comment-16204167
]
Hudson commented on HBASE-18505:
FAILURE: Integrated in Jenkins build HBase-1.5 #98 (See
[https://builds.apache.org/job/HBase-1.5/98/])
HBASE-18505 Yetus only run root when all modules changed (mdrob: rev
aeffd3ad76fe5da009391dbd41d1f2e66e5e3ec8)
* (edit) dev-support/hbase-personality.sh
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-18505.actual.patch, HBASE-18505.patch,
> HBASE-18505.v2.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18986) Remove unnecessary null check after CellUtil.cloneQualifier()
[
https://issues.apache.org/jira/browse/HBASE-18986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204162#comment-16204162
]
Hadoop QA commented on HBASE-18986:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
10s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
57s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
2s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
2s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
34m 51s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}100m
43s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
18s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}154m 31s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18986 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12892111/HBASE-18986.master.000.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 2182325a804c 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 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 / f6a8a76 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9105/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9105/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
[jira] [Updated] (HBASE-18974) Document "Becoming a Committer"
[ https://issues.apache.org/jira/browse/HBASE-18974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18974: --- Status: Patch Available (was: Open) > Document "Becoming a Committer" > --- > > Key: HBASE-18974 > URL: https://issues.apache.org/jira/browse/HBASE-18974 > Project: HBase > Issue Type: Bug > Components: community, documentation >Reporter: Mike Drob >Assignee: Mike Drob > Attachments: HBASE-18974.patch > > > Based on the mailing list discussion at > https://lists.apache.org/thread.html/81c633cbe1f6f78421cbdad5b9549643c67803a723a9d86a513264c0@%3Cdev.hbase.apache.org%3E > it sounds like we should record some of the thoughts for future contributors > to refer to. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16338) update jackson to 2.y
[
https://issues.apache.org/jira/browse/HBASE-16338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204147#comment-16204147
]
Mike Drob commented on HBASE-16338:
---
Also, the error in hbase-rest install is:
{noformat}
[WARNING] The POM for org.apache.hbase:hbase-client:jar:3.0.0-SNAPSHOT is
invalid, transitive dependencies (if any) will not be available, enable debug
logging for more details
[WARNING] The POM for org.apache.hbase:hbase-server:jar:3.0.0-SNAPSHOT is
invalid, transitive dependencies (if any) will not be available, enable debug
logging for more details
[WARNING] The POM for org.apache.hbase:hbase-mapreduce:jar:3.0.0-SNAPSHOT is
invalid, transitive dependencies (if any) will not be available, enable debug
logging for more details
[WARNING] The POM for org.apache.hbase:hbase-mapreduce:jar:tests:3.0.0-SNAPSHOT
is invalid, transitive dependencies (if any) will not be available, enable
debug logging for more details
[WARNING] The POM for org.apache.hbase:hbase-server:jar:tests:3.0.0-SNAPSHOT is
invalid, transitive dependencies (if any) will not be available, enable debug
logging for more details
{noformat}
but I can't reproduce this locally.
It looks like it is using maven 3.5.0, but I'm not sure what is wrong with the
pom.xml... How do I pass debugging flags to yetus to pass to maven?
> update jackson to 2.y
> -
>
> Key: HBASE-16338
> URL: https://issues.apache.org/jira/browse/HBASE-16338
> Project: HBase
> Issue Type: Task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Mike Drob
> Fix For: 2.0.0-beta-2
>
> Attachments: 16338.txt, HBASE-16338.v2.patch, HBASE-16338.v3.patch,
> HBASE-16338.v5.patch, HBASE-16338.v6.patch, HBASE-16338.v7.patch,
> HBASE-16338.v8.patch, HBASE-16338.v9.patch
>
>
> Our jackson dependency is from ~3 years ago. Update to the jackson 2.y line,
> using 2.7.0+.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19006) Fix TestIncrementalBackupWithBulkLoad under hadoop3
[ https://issues.apache.org/jira/browse/HBASE-19006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204136#comment-16204136 ] Ted Yu commented on HBASE-19006: Can you attach the test output for the failed test ? thanks > Fix TestIncrementalBackupWithBulkLoad under hadoop3 > --- > > Key: HBASE-19006 > URL: https://issues.apache.org/jira/browse/HBASE-19006 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Critical > Fix For: 2.0.0-beta-2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16338) update jackson to 2.y
[ https://issues.apache.org/jira/browse/HBASE-16338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204128#comment-16204128 ] Mike Drob commented on HBASE-16338: --- It looks like I get a scala compiler crash on jenkins, but not locally. I am not sure I know how to approach that... > update jackson to 2.y > - > > Key: HBASE-16338 > URL: https://issues.apache.org/jira/browse/HBASE-16338 > Project: HBase > Issue Type: Task > Components: dependencies >Reporter: Sean Busbey >Assignee: Mike Drob > Fix For: 2.0.0-beta-2 > > Attachments: 16338.txt, HBASE-16338.v2.patch, HBASE-16338.v3.patch, > HBASE-16338.v5.patch, HBASE-16338.v6.patch, HBASE-16338.v7.patch, > HBASE-16338.v8.patch, HBASE-16338.v9.patch > > > Our jackson dependency is from ~3 years ago. Update to the jackson 2.y line, > using 2.7.0+. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18912) Update Admin methods to return Lists instead of arrays
[
https://issues.apache.org/jira/browse/HBASE-18912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204112#comment-16204112
]
Peter Somogyi commented on HBASE-18912:
---
I agree with you [~zghaobac]! Using List sounds better but changing to that is
not so easy. Currently there are 2 occurrences in {{Table}} that return array
and the corresponding methods in {{AsyncTable}} use List.
> Update Admin methods to return Lists instead of arrays
> --
>
> Key: HBASE-18912
> URL: https://issues.apache.org/jira/browse/HBASE-18912
> Project: HBase
> Issue Type: Sub-task
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0-beta-1
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[
https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204109#comment-16204109
]
Chia-Ping Tsai commented on HBASE-15410:
v4 LGTM.
nit:
{code}
+import java.util.Collection;
import java.util.Collections;
+import java.util.HashSet;
import java.util.List;
+import java.util.Set;
{code}
remove the unused imports.
{code}
- private Filter seekHintFilter = null;
+ private Collection seekHintFilter = new ArrayList();
{code}
seekHintFilter -> seekHintFilter"s"
> Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList
> return SEEK_NEXT_USING_HINT
> ---
>
> Key: HBASE-15410
> URL: https://issues.apache.org/jira/browse/HBASE-15410
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Ted Yu
> Labels: filter, perfomance
> Fix For: 1.5.0, 2.0.0-alpha-3, HBASE-18410
>
> Attachments: 15410-wip.patch, 15410.branch-1.patch, 15410.v1.patch,
> 15410.v2.patch, 15410.v3.patch, 15410.v4.patch
>
>
> As Preston mentioned in the comment in HBASE-15243:
> https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557
> An optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek
> to the highest hint (Any previous/lower row won't be accepted by the filter
> returning that seek).
> This JIRA is to explore this potential optimization.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204105#comment-16204105
]
Hudson commented on HBASE-18505:
FAILURE: Integrated in Jenkins build HBase-2.0 #680 (See
[https://builds.apache.org/job/HBase-2.0/680/])
HBASE-18505 Yetus only run root when all modules changed (mdrob: rev
822cc1ed73729197d535078beea9aba12946fbe9)
* (edit) dev-support/hbase-personality.sh
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-18505.actual.patch, HBASE-18505.patch,
> HBASE-18505.v2.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18998) processor.getRowsToLock() always assumes there is some row being locked
[
https://issues.apache.org/jira/browse/HBASE-18998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204104#comment-16204104
]
Hudson commented on HBASE-18998:
FAILURE: Integrated in Jenkins build HBase-2.0 #680 (See
[https://builds.apache.org/job/HBase-2.0/680/])
HBASE-18998 processor.getRowsToLock() always assumes there is some row (tedyu:
rev 501f8b95091e9ec5d774e5bd536639c49580abf3)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> processor.getRowsToLock() always assumes there is some row being locked
> ---
>
> Key: HBASE-18998
> URL: https://issues.apache.org/jira/browse/HBASE-18998
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: 18998.v1.txt
>
>
> During testing, we observed the following exception:
> {code}
> 2017-10-12 02:52:26,683|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|1/1 DROP TABLE
> testTable;
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|17/10/12 02:52:30 WARN
> ipc.CoprocessorRpcChannel: Call failed on IOException
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|org.apache.hadoop.hbase.DoNotRetryIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException: TESTTABLE: null
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:93)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1671)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:14347)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7849)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1980)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1962)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32389)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2150)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:187)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:167)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|Caused by:
> java.util.NoSuchElementException
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> java.util.Collections$EmptyIterator.next(Collections.java:4189)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.processRowsWithLocks(HRegion.java:7137)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.mutateRowsWithLocks(HRegion.java:6980)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.mutateRowsWithLocks(MetaDataEndpointImpl.java:1966)
> 2017-10-12 02:52:30,323|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
>
[jira] [Comment Edited] (HBASE-18843) Add DistCp support to incremental backup with bulk loading
[ https://issues.apache.org/jira/browse/HBASE-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204091#comment-16204091 ] Vladimir Rodionov edited comment on HBASE-18843 at 10/13/17 7:53 PM: - Thanks, [~elserj]. I opened HBASE-19006 to address hadoop3 issue. was (Author: vrodionov): Thanks, [~elserj]. I opened HBASE-19906 to address hadoop3 issue. > Add DistCp support to incremental backup with bulk loading > -- > > Key: HBASE-18843 > URL: https://issues.apache.org/jira/browse/HBASE-18843 > Project: HBase > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18843-v1.patch, HBASE-18843-v2.patch, > HBASE-18843-v4.patch, HBASE-18843-v5.patch, HBASE-18843-v6.patch, > HBASE-18843-v7.patch, HBASE-18843-v8.patch > > > Currently, we copy bulk loaded files to backup one-by-one on a client side > (where backup create runs). This has to be replaced with DistCp copying. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18843) Add DistCp support to incremental backup with bulk loading
[ https://issues.apache.org/jira/browse/HBASE-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204091#comment-16204091 ] Vladimir Rodionov commented on HBASE-18843: --- Thanks, [~elserj]. I opened HBASE-19906 to address hadoop3 issue. > Add DistCp support to incremental backup with bulk loading > -- > > Key: HBASE-18843 > URL: https://issues.apache.org/jira/browse/HBASE-18843 > Project: HBase > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18843-v1.patch, HBASE-18843-v2.patch, > HBASE-18843-v4.patch, HBASE-18843-v5.patch, HBASE-18843-v6.patch, > HBASE-18843-v7.patch, HBASE-18843-v8.patch > > > Currently, we copy bulk loaded files to backup one-by-one on a client side > (where backup create runs). This has to be replaced with DistCp copying. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18997) Remove the redundant methods in RegionInfo
[
https://issues.apache.org/jira/browse/HBASE-18997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18997:
---
Status: Open (was: Patch Available)
> Remove the redundant methods in RegionInfo
> --
>
> Key: HBASE-18997
> URL: https://issues.apache.org/jira/browse/HBASE-18997
> Project: HBase
> Issue Type: Bug
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18997.v0.patch, HBASE-18997.v1.patch
>
>
> The {{isSystemTable}} is short cut to {{TableName}}, and the {{isMetaTable}}
> is always equal with {{isMetaRegion}}. Our IA.Public interface should be
> minimalist
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18960) A few bug fixes and minor improvements around batchMutate()
[ https://issues.apache.org/jira/browse/HBASE-18960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204084#comment-16204084 ] Umesh Agashe commented on HBASE-18960: -- Latest patch has changes per review comments so far. Its ready for merge. Please add review feedback/ +1s for the changes. thanks! > A few bug fixes and minor improvements around batchMutate() > --- > > Key: HBASE-18960 > URL: https://issues.apache.org/jira/browse/HBASE-18960 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 2.0.0-alpha-3 >Reporter: Umesh Agashe >Assignee: Umesh Agashe > Fix For: 2.0.0-alpha-4 > > Attachments: hbase-18960.master.001.patch, > hbase-18960.master.002.patch, hbase-18960.master.003.patch, > hbase-18960.master.004.patch, hbase-18960.master.005.patch, > hbase-18960.master.005.patch, hbase-18960.master.006.patch, > hbase-18960.master.007.patch, hbase-18960.master.008.patch > > > Batch validation and preparation can be done before we start iterating over > batch operations for writes. observedExceptions, familyCellMaps and > durability can be stored in BatchOperation as they are batch wide. For all > operations, done by preBatchMutate() CP hook, operation status needs to be > SUCCESS. Modify and use doWALAppend() from doMiniBatchMutate(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19006) Fix TestIncrementalBackupWithBulkLoad under hadoop3
Vladimir Rodionov created HBASE-19006: - Summary: Fix TestIncrementalBackupWithBulkLoad under hadoop3 Key: HBASE-19006 URL: https://issues.apache.org/jira/browse/HBASE-19006 Project: HBase Issue Type: Bug Reporter: Vladimir Rodionov Assignee: Vladimir Rodionov Priority: Critical Fix For: 2.0.0-beta-2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18997) Remove the redundant methods in RegionInfo
[
https://issues.apache.org/jira/browse/HBASE-18997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18997:
---
Status: Patch Available (was: Open)
> Remove the redundant methods in RegionInfo
> --
>
> Key: HBASE-18997
> URL: https://issues.apache.org/jira/browse/HBASE-18997
> Project: HBase
> Issue Type: Bug
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18997.v0.patch, HBASE-18997.v1.patch
>
>
> The {{isSystemTable}} is short cut to {{TableName}}, and the {{isMetaTable}}
> is always equal with {{isMetaRegion}}. Our IA.Public interface should be
> minimalist
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18997) Remove the redundant methods in RegionInfo
[
https://issues.apache.org/jira/browse/HBASE-18997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18997:
---
Attachment: HBASE-18997.v1.patch
v1
# fix the TestPriorityRpc
> Remove the redundant methods in RegionInfo
> --
>
> Key: HBASE-18997
> URL: https://issues.apache.org/jira/browse/HBASE-18997
> Project: HBase
> Issue Type: Bug
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18997.v0.patch, HBASE-18997.v1.patch
>
>
> The {{isSystemTable}} is short cut to {{TableName}}, and the {{isMetaTable}}
> is always equal with {{isMetaRegion}}. Our IA.Public interface should be
> minimalist
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18350) RSGroups are broken under AMv2
[
https://issues.apache.org/jira/browse/HBASE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204072#comment-16204072
]
Hadoop QA commented on HBASE-18350:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 13m
46s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
45s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
57s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
50s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
9s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
22s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
58s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
12s{color} | {color:red} The patch generated 5 new + 13 unchanged - 4 fixed =
18 total (was 17) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
4s{color} | {color:red} The patch generated 6 new + 26 unchanged - 1 fixed = 32
total (was 27) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
42s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
47m 42s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}106m
40s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
10s{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m
29s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
2s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}213m 21s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18350 |
| JIRA Patch URL |
[jira] [Comment Edited] (HBASE-18843) Add DistCp support to incremental backup with bulk loading
[ https://issues.apache.org/jira/browse/HBASE-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204063#comment-16204063 ] Josh Elser edited comment on HBASE-18843 at 10/13/17 7:34 PM: -- Thanks, Vlad! I had a chat with Vlad earlier today on this issue. Vlad's take was that Distcp is busted in Hadoop3 presently -- stacktraces down in the weeds of Hadoop that we haven't yet unraveled. I don't want us to be in a situation where this is "held hostage" by Hadoop3 bugs that need to be worked out, but I also want to make sure that we don't ignore Hadoop3 issues when we know about 'em. My opinion is that we should get a follow-on issues filed (I guess here in HBASE for now, can switch it to the appropriate Hadoop JIRA project after investigation) for the Hadoop3 runtime issue, and get this committed. _Edit_: oh, and +1 pending QA. was (Author: elserj): Thanks, Vlad! I had a chat with Vlad earlier today on this issue. Vlad's take was that Distcp is busted in Hadoop3 presently -- stacktraces down in the weeds of Hadoop that we haven't yet unraveled. I don't want us to be in a situation where this is "held hostage" by Hadoop3 bugs that need to be worked out, but I also want to make sure that we don't ignore Hadoop3 issues when we know about 'em. My opinion is that we should get a follow-on issues filed (I guess here in HBASE for now, can switch it to the appropriate Hadoop JIRA project after investigation) for the Hadoop3 runtime issue, and get this committed. > Add DistCp support to incremental backup with bulk loading > -- > > Key: HBASE-18843 > URL: https://issues.apache.org/jira/browse/HBASE-18843 > Project: HBase > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18843-v1.patch, HBASE-18843-v2.patch, > HBASE-18843-v4.patch, HBASE-18843-v5.patch, HBASE-18843-v6.patch, > HBASE-18843-v7.patch, HBASE-18843-v8.patch > > > Currently, we copy bulk loaded files to backup one-by-one on a client side > (where backup create runs). This has to be replaced with DistCp copying. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18843) Add DistCp support to incremental backup with bulk loading
[ https://issues.apache.org/jira/browse/HBASE-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204063#comment-16204063 ] Josh Elser commented on HBASE-18843: Thanks, Vlad! I had a chat with Vlad earlier today on this issue. Vlad's take was that Distcp is busted in Hadoop3 presently -- stacktraces down in the weeds of Hadoop that we haven't yet unraveled. I don't want us to be in a situation where this is "held hostage" by Hadoop3 bugs that need to be worked out, but I also want to make sure that we don't ignore Hadoop3 issues when we know about 'em. My opinion is that we should get a follow-on issues filed (I guess here in HBASE for now, can switch it to the appropriate Hadoop JIRA project after investigation) for the Hadoop3 runtime issue, and get this committed. > Add DistCp support to incremental backup with bulk loading > -- > > Key: HBASE-18843 > URL: https://issues.apache.org/jira/browse/HBASE-18843 > Project: HBase > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18843-v1.patch, HBASE-18843-v2.patch, > HBASE-18843-v4.patch, HBASE-18843-v5.patch, HBASE-18843-v6.patch, > HBASE-18843-v7.patch, HBASE-18843-v8.patch > > > Currently, we copy bulk loaded files to backup one-by-one on a client side > (where backup create runs). This has to be replaced with DistCp copying. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18843) Add DistCp support to incremental backup with bulk loading
[ https://issues.apache.org/jira/browse/HBASE-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-18843: -- Attachment: HBASE-18843-v8.patch v8. still not compatible with hadoop3. will open separate JIRA. [~te...@apache.org], [~elserj] can we commit this one? > Add DistCp support to incremental backup with bulk loading > -- > > Key: HBASE-18843 > URL: https://issues.apache.org/jira/browse/HBASE-18843 > Project: HBase > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18843-v1.patch, HBASE-18843-v2.patch, > HBASE-18843-v4.patch, HBASE-18843-v5.patch, HBASE-18843-v6.patch, > HBASE-18843-v7.patch, HBASE-18843-v8.patch > > > Currently, we copy bulk loaded files to backup one-by-one on a client side > (where backup create runs). This has to be replaced with DistCp copying. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18960) A few bug fixes and minor improvements around batchMutate()
[ https://issues.apache.org/jira/browse/HBASE-18960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Umesh Agashe updated HBASE-18960: - Attachment: hbase-18960.master.008.patch Changes per latest review comment. Also retry for build. Last patch got skipped by yetus build. > A few bug fixes and minor improvements around batchMutate() > --- > > Key: HBASE-18960 > URL: https://issues.apache.org/jira/browse/HBASE-18960 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 2.0.0-alpha-3 >Reporter: Umesh Agashe >Assignee: Umesh Agashe > Fix For: 2.0.0-alpha-4 > > Attachments: hbase-18960.master.001.patch, > hbase-18960.master.002.patch, hbase-18960.master.003.patch, > hbase-18960.master.004.patch, hbase-18960.master.005.patch, > hbase-18960.master.005.patch, hbase-18960.master.006.patch, > hbase-18960.master.007.patch, hbase-18960.master.008.patch > > > Batch validation and preparation can be done before we start iterating over > batch operations for writes. observedExceptions, familyCellMaps and > durability can be stored in BatchOperation as they are batch wide. For all > operations, done by preBatchMutate() CP hook, operation status needs to be > SUCCESS. Modify and use doWALAppend() from doMiniBatchMutate(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204048#comment-16204048 ] stack commented on HBASE-12260: --- bq. I considered this a mess in a fashion similar to the HRS+RSS+IRSS noted above and it did not align w/ the radical retrofit done here. 'mess' in the above is the wrong word. I should have said something like added-complexity. Also, I come to the opinion above after doing the work in here (Anoop was ahead of me in his RSS refactor). To answer [~anoop.hbase] more directly bq. the name is the issue or having 2 interfaces stack? I think it the latter Anoop. There will be three Interfaces actually -- Server, CoprocessorRegionServerServices, RegionServerServices, and then the HRS Implementation. It strikes me as complicating adding in another tier of Interfaces. CPRSS is not too bad because it clear that it is for CPs exclusively but then having this in our implementation hierarchy doesn't seem right either (or duping methods once in RSS and then in CPRSS so CPRSS is a mix-in seems complicating also). I chatted w/ my coworkers here. One thought that came out of the discussion was bulking up Server. Given Master is a RegionServer now, could we add enough to Server Interface to make CPs happy? I'll take a look. > MasterServices needs a short-back-and-sides; pare-back exposure of internals > and IA.Private classes > --- > > Key: HBASE-12260 > URL: https://issues.apache.org/jira/browse/HBASE-12260 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: ryan rawson >Assignee: stack >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-12260.master.001.patch, > HBASE-12260.master.002.patch, HBASE-12260.master.003.patch, > HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, > HBASE-12260.master.006.patch, HBASE-12260.master.007.patch, > HBASE-12260.master.008.patch, HBASE-12260.master.009.patch, > HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, > HBASE-12260.master.011.patch, HBASE-12260.master.012.patch, > HBASE-12260.master.013.patch, HBASE-12260.master.014.patch > > > A major issue with MasterServices is the MasterCoprocessorEnvironment exposes > this class even though MasterServices is tagged with > @InterfaceAudience.Private > This means that the entire internals of the HMaster is essentially part of > the coprocessor API. Many of the classes returned by the MasterServices API > are highly internal, extremely powerful, and subject to constant change. > Perhaps a new API to replace MasterServices that is use-case focused, and > justified based on real world co-processors would suit things better. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-13346) Clean up Filter package for post 1.0 s/KeyValue/Cell/g
[
https://issues.apache.org/jira/browse/HBASE-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated HBASE-13346:
-
Attachment: HBASE-13346.master.007.patch
> Clean up Filter package for post 1.0 s/KeyValue/Cell/g
> --
>
> Key: HBASE-13346
> URL: https://issues.apache.org/jira/browse/HBASE-13346
> Project: HBase
> Issue Type: Bug
> Components: API, Filters
>Affects Versions: 2.0.0
>Reporter: Lars George
>Assignee: Tamas Penzes
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-13346.master.001.patch,
> HBASE-13346.master.002.patch, HBASE-13346.master.003.patch,
> HBASE-13346.master.003.patch, HBASE-13346.master.004.patch,
> HBASE-13346.master.005.patch, HBASE-13346.master.006.patch,
> HBASE-13346.master.007.patch
>
>
> Since we have a bit of a messy Filter API with KeyValue vs Cell reference
> mixed up all over the place, I recommend cleaning this up once and for all.
> There should be no {{KeyValue}} (or {{kv}}, {{kvs}} etc.) in any method or
> parameter name.
> This includes deprecating and renaming filters too, for example
> {{FirstKeyOnlyFilter}}, which really should be named {{FirstKeyValueFilter}}
> as it does _not_ just return the key, but the entire cell. It should be
> deprecated and renamed to {{FirstCellFilter}} (or {{FirstColumnFilter}} if
> you prefer).
> In general we should clarify and settle on {{KeyValue}} vs {{Cell}} vs
> {{Column}} in our naming. The latter two are the only ones going forward with
> the public API, and are used synonymous. We should carefully check which is
> better suited (is it really a specific cell, or the newest cell, aka the
> newest column value) and settle on a naming schema.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204028#comment-16204028 ] Sean Busbey commented on HBASE-15410: - v4 looks fine. > Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList > return SEEK_NEXT_USING_HINT > --- > > Key: HBASE-15410 > URL: https://issues.apache.org/jira/browse/HBASE-15410 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Labels: filter, perfomance > Fix For: 1.5.0, 2.0.0-alpha-3, HBASE-18410 > > Attachments: 15410-wip.patch, 15410.branch-1.patch, 15410.v1.patch, > 15410.v2.patch, 15410.v3.patch, 15410.v4.patch > > > As Preston mentioned in the comment in HBASE-15243: > https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557 > An optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek > to the highest hint (Any previous/lower row won't be accepted by the filter > returning that seek). > This JIRA is to explore this potential optimization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204022#comment-16204022 ] Mike Drob commented on HBASE-15410: --- You have some unused imports still hanging about. Otherwise LGTM. > Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList > return SEEK_NEXT_USING_HINT > --- > > Key: HBASE-15410 > URL: https://issues.apache.org/jira/browse/HBASE-15410 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Labels: filter, perfomance > Fix For: 1.5.0, 2.0.0-alpha-3, HBASE-18410 > > Attachments: 15410-wip.patch, 15410.branch-1.patch, 15410.v1.patch, > 15410.v2.patch, 15410.v3.patch, 15410.v4.patch > > > As Preston mentioned in the comment in HBASE-15243: > https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557 > An optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek > to the highest hint (Any previous/lower row won't be accepted by the filter > returning that seek). > This JIRA is to explore this potential optimization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15410: --- Attachment: 15410.v4.patch Patch v4 addresses Mike's comment. > Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList > return SEEK_NEXT_USING_HINT > --- > > Key: HBASE-15410 > URL: https://issues.apache.org/jira/browse/HBASE-15410 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Labels: filter, perfomance > Fix For: 1.5.0, 2.0.0-alpha-3, HBASE-18410 > > Attachments: 15410-wip.patch, 15410.branch-1.patch, 15410.v1.patch, > 15410.v2.patch, 15410.v3.patch, 15410.v4.patch > > > As Preston mentioned in the comment in HBASE-15243: > https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557 > An optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek > to the highest hint (Any previous/lower row won't be accepted by the filter > returning that seek). > This JIRA is to explore this potential optimization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[
https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204005#comment-16204005
]
Mike Drob commented on HBASE-15410:
---
Is it safe to use {{HashSet}} here? I took a look at a handful of
filter implementations and didn't see {{equals}} or {{hashCode}} implemented
anywhere. Are set semantics important for what we need? {{Collection
filters = new ArrayList<>()}} is likely better.
> Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList
> return SEEK_NEXT_USING_HINT
> ---
>
> Key: HBASE-15410
> URL: https://issues.apache.org/jira/browse/HBASE-15410
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Ted Yu
> Labels: filter, perfomance
> Fix For: 1.5.0, 2.0.0-alpha-3, HBASE-18410
>
> Attachments: 15410-wip.patch, 15410.branch-1.patch, 15410.v1.patch,
> 15410.v2.patch, 15410.v3.patch
>
>
> As Preston mentioned in the comment in HBASE-15243:
> https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557
> An optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek
> to the highest hint (Any previous/lower row won't be accepted by the filter
> returning that seek).
> This JIRA is to explore this potential optimization.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18998) processor.getRowsToLock() always assumes there is some row being locked
[
https://issues.apache.org/jira/browse/HBASE-18998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16204002#comment-16204002
]
Hudson commented on HBASE-18998:
SUCCESS: Integrated in Jenkins build HBase-1.4 #952 (See
[https://builds.apache.org/job/HBase-1.4/952/])
HBASE-18998 processor.getRowsToLock() always assumes there is some row (tedyu:
rev f2d85c306c3bb49ffc36169927aa255c6b872cfb)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> processor.getRowsToLock() always assumes there is some row being locked
> ---
>
> Key: HBASE-18998
> URL: https://issues.apache.org/jira/browse/HBASE-18998
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: 18998.v1.txt
>
>
> During testing, we observed the following exception:
> {code}
> 2017-10-12 02:52:26,683|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|1/1 DROP TABLE
> testTable;
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|17/10/12 02:52:30 WARN
> ipc.CoprocessorRpcChannel: Call failed on IOException
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|org.apache.hadoop.hbase.DoNotRetryIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException: TESTTABLE: null
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:93)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1671)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:14347)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7849)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1980)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1962)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32389)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2150)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:187)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:167)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|Caused by:
> java.util.NoSuchElementException
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> java.util.Collections$EmptyIterator.next(Collections.java:4189)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.processRowsWithLocks(HRegion.java:7137)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.mutateRowsWithLocks(HRegion.java:6980)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.mutateRowsWithLocks(MetaDataEndpointImpl.java:1966)
> 2017-10-12 02:52:30,323|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
>
[jira] [Created] (HBASE-19005) Mutation batch should not accept operations with different durabilities
Umesh Agashe created HBASE-19005: Summary: Mutation batch should not accept operations with different durabilities Key: HBASE-19005 URL: https://issues.apache.org/jira/browse/HBASE-19005 Project: HBase Issue Type: Bug Components: regionserver Affects Versions: 2.0.0-alpha-3 Reporter: Umesh Agashe Assignee: Umesh Agashe Fix For: 2.0.0-beta-1 Javadoc and change client side API to not accept operations with different durabilities in a mutation batch. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203974#comment-16203974
]
Hudson commented on HBASE-18505:
SUCCESS: Integrated in Jenkins build HBase-1.2-IT #973 (See
[https://builds.apache.org/job/HBase-1.2-IT/973/])
HBASE-18505 Yetus only run root when all modules changed (mdrob: rev
f1c145b92505f32507096a5a1753485d625da92f)
* (edit) dev-support/hbase-personality.sh
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-18505.actual.patch, HBASE-18505.patch,
> HBASE-18505.v2.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18998) processor.getRowsToLock() always assumes there is some row being locked
[
https://issues.apache.org/jira/browse/HBASE-18998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203970#comment-16203970
]
Hudson commented on HBASE-18998:
SUCCESS: Integrated in Jenkins build HBase-1.1-JDK8 #2006 (See
[https://builds.apache.org/job/HBase-1.1-JDK8/2006/])
HBASE-18998 processor.getRowsToLock() always assumes there is some row (tedyu:
rev 3a86bfc26282ea63d917c9568a122927cdbe)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> processor.getRowsToLock() always assumes there is some row being locked
> ---
>
> Key: HBASE-18998
> URL: https://issues.apache.org/jira/browse/HBASE-18998
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: 18998.v1.txt
>
>
> During testing, we observed the following exception:
> {code}
> 2017-10-12 02:52:26,683|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|1/1 DROP TABLE
> testTable;
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|17/10/12 02:52:30 WARN
> ipc.CoprocessorRpcChannel: Call failed on IOException
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|org.apache.hadoop.hbase.DoNotRetryIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException: TESTTABLE: null
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:93)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1671)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:14347)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7849)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1980)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1962)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32389)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2150)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:187)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:167)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|Caused by:
> java.util.NoSuchElementException
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> java.util.Collections$EmptyIterator.next(Collections.java:4189)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.processRowsWithLocks(HRegion.java:7137)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.mutateRowsWithLocks(HRegion.java:6980)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.mutateRowsWithLocks(MetaDataEndpointImpl.java:1966)
> 2017-10-12 02:52:30,323|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
>
[jira] [Commented] (HBASE-18998) processor.getRowsToLock() always assumes there is some row being locked
[
https://issues.apache.org/jira/browse/HBASE-18998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203965#comment-16203965
]
Hudson commented on HBASE-18998:
FAILURE: Integrated in Jenkins build HBase-1.5 #97 (See
[https://builds.apache.org/job/HBase-1.5/97/])
HBASE-18998 processor.getRowsToLock() always assumes there is some row (tedyu:
rev 8d6902ae77f0942232fd51c023c48e72cf37e87c)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> processor.getRowsToLock() always assumes there is some row being locked
> ---
>
> Key: HBASE-18998
> URL: https://issues.apache.org/jira/browse/HBASE-18998
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: 18998.v1.txt
>
>
> During testing, we observed the following exception:
> {code}
> 2017-10-12 02:52:26,683|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|1/1 DROP TABLE
> testTable;
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|17/10/12 02:52:30 WARN
> ipc.CoprocessorRpcChannel: Call failed on IOException
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|org.apache.hadoop.hbase.DoNotRetryIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException: TESTTABLE: null
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:93)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1671)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:14347)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7849)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1980)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1962)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32389)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2150)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:187)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:167)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|Caused by:
> java.util.NoSuchElementException
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> java.util.Collections$EmptyIterator.next(Collections.java:4189)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.processRowsWithLocks(HRegion.java:7137)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.mutateRowsWithLocks(HRegion.java:6980)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.mutateRowsWithLocks(MetaDataEndpointImpl.java:1966)
> 2017-10-12 02:52:30,323|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
>
[jira] [Commented] (HBASE-18998) processor.getRowsToLock() always assumes there is some row being locked
[
https://issues.apache.org/jira/browse/HBASE-18998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203957#comment-16203957
]
Hudson commented on HBASE-18998:
SUCCESS: Integrated in Jenkins build HBase-1.1-JDK7 #1922 (See
[https://builds.apache.org/job/HBase-1.1-JDK7/1922/])
HBASE-18998 processor.getRowsToLock() always assumes there is some row (tedyu:
rev 3a86bfc26282ea63d917c9568a122927cdbe)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> processor.getRowsToLock() always assumes there is some row being locked
> ---
>
> Key: HBASE-18998
> URL: https://issues.apache.org/jira/browse/HBASE-18998
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: 18998.v1.txt
>
>
> During testing, we observed the following exception:
> {code}
> 2017-10-12 02:52:26,683|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|1/1 DROP TABLE
> testTable;
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|17/10/12 02:52:30 WARN
> ipc.CoprocessorRpcChannel: Call failed on IOException
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|org.apache.hadoop.hbase.DoNotRetryIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException: TESTTABLE: null
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:93)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1671)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:14347)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7849)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1980)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1962)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32389)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2150)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:187)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:167)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|Caused by:
> java.util.NoSuchElementException
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> java.util.Collections$EmptyIterator.next(Collections.java:4189)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.processRowsWithLocks(HRegion.java:7137)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.mutateRowsWithLocks(HRegion.java:6980)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.mutateRowsWithLocks(MetaDataEndpointImpl.java:1966)
> 2017-10-12 02:52:30,323|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
>
[jira] [Updated] (HBASE-18986) Remove unnecessary null check after CellUtil.cloneQualifier()
[
https://issues.apache.org/jira/browse/HBASE-18986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerry He updated HBASE-18986:
-
Attachment: HBASE-18986.master.000.patch
Yup, after the clone, we will get a byte[0] -- EMPTY_BYTE_ARRAY anyway if no
qual.
Retry.
> Remove unnecessary null check after CellUtil.cloneQualifier()
> -
>
> Key: HBASE-18986
> URL: https://issues.apache.org/jira/browse/HBASE-18986
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18986.master.000.patch,
> HBASE-18986.master.000.patch
>
>
> In master branch,
> {code:title=hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java|borderStyle=solid}
> // From line 2858
> public void prepareDeleteTimestamps(Mutation mutation, Map List> familyMap,
> byte[] byteNow) throws IOException {
> for (Map.Entry e : familyMap.entrySet()) {
> // ...
> for (int i=0; i < listSize; i++) {
> // ...
> if (cell.getTimestamp() == HConstants.LATEST_TIMESTAMP &&
> CellUtil.isDeleteType(cell)) {
> byte[] qual = CellUtil.cloneQualifier(cell);
> if (qual == null) qual = HConstants.EMPTY_BYTE_ARRAY; // <-- here
> ...
> {code}
> Might {{if (qual == null) qual = HConstants.EMPTY_BYTE_ARRAY;}} be removed?
> Could it be null after CellUtil.cloneQualifier()?
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java|borderStyle=solid}
> public static byte[] cloneQualifier(Cell cell){
> byte[] output = new byte[cell.getQualifierLength()];
> copyQualifierTo(cell, output, 0);
> return output;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18901) Support build with CMake
[
https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203939#comment-16203939
]
Josh Elser commented on HBASE-18901:
Some problems I'm seeing are related to the {{CXX11_ABI=0}} option in
{{CFLAGS}}/{{CXXFLAGS}}. I ran into this using the system-installed glog
package. e.g.
{noformat}
/usr/include/glog/logging.h:672: undefined reference to
`google::base::CheckOpMessageBuilder::NewString()'
./.libs/libfollybase.a(Conv.o): In function `std::string*
google::MakeCheckOpString(unsigned long const&,
unsigned long const&, char const*)':
/usr/include/glog/logging.h:672: undefined reference to
`google::base::CheckOpMessageBuilder::NewString()'
./.libs/libfollybase.a(Format.o): In function `std::string*
google::MakeCheckOpString(int const&, int const&, char const*)':
/usr/include/glog/logging.h:672: undefined reference to
`google::base::CheckOpMessageBuilder::NewString()'
{noformat}
Looking at the error message from above around protobuf. I wonder if that isn't
also the same problem:
{noformat}
libhbaseclient.a(ClusterId.pb.cc.o):(.rodata._ZTVN5hbase2pb9ClusterIdE[_ZTVN5hbase2pb9ClusterIdE]+0x58):
undefined reference to
`google::protobuf::Message::InitializationErrorString[abi:cxx11]() const'
{noformat}
We're configuring things to use the old ABI (which would affect std::string and
std::list). Given the troubleshooting section on
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html, we just
need to make sure that we're consistently using the new or old ABI (and also
knowing which the libraries on the system we're linking against are using!)
> Support build with CMake
>
>
> Key: HBASE-18901
> URL: https://issues.apache.org/jira/browse/HBASE-18901
> Project: HBase
> Issue Type: Sub-task
>Reporter: Josh Elser
>Assignee: marco polo
> Labels: C++
> Fix For: HBASE-14850
>
> Attachments: HBASE-18901.v1.HBASE-14850.patch,
> HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch,
> HBASE-18901.v4.HBASE-14850.patch
>
>
> I've co-opted some help from folks in trying to support CMake as the build
> tool instead of Buck.
> They have something working, but need to consolidate the patch. Filing an
> issue for them to put a patch on.
> FYI [~enis], [~tedyu]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203936#comment-16203936
]
Hudson commented on HBASE-18505:
FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #308 (See
[https://builds.apache.org/job/HBase-1.3-JDK7/308/])
HBASE-18505 Yetus only run root when all modules changed (mdrob: rev
9edc26767f74f008ce5039c58e06ee1a6fe921fa)
* (edit) dev-support/hbase-personality.sh
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-18505.actual.patch, HBASE-18505.patch,
> HBASE-18505.v2.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203934#comment-16203934
]
Hudson commented on HBASE-18505:
FAILURE: Integrated in Jenkins build HBase-1.3-JDK8 #323 (See
[https://builds.apache.org/job/HBase-1.3-JDK8/323/])
HBASE-18505 Yetus only run root when all modules changed (mdrob: rev
9edc26767f74f008ce5039c58e06ee1a6fe921fa)
* (edit) dev-support/hbase-personality.sh
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-18505.actual.patch, HBASE-18505.patch,
> HBASE-18505.v2.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
