[jira] [Commented] (HBASE-19723) hbase-thrift declares slf4j-api twice
[
https://issues.apache.org/jira/browse/HBASE-19723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315090#comment-16315090
]
Chia-Ping Tsai commented on HBASE-19723:
+1
> hbase-thrift declares slf4j-api twice
> -
>
> Key: HBASE-19723
> URL: https://issues.apache.org/jira/browse/HBASE-19723
> Project: HBase
> Issue Type: Improvement
> Components: Thrift
>Affects Versions: 3.0.0
>Reporter: Jan Hentschel
>Assignee: Jan Hentschel
>Priority: Trivial
> Attachments: HBASE-19723.master.001.patch
>
>
> Currently *hbase-thrift* declares the dependency {{slf4j-api}} twice
> resulting in the following warning
> {code}
> [WARNING] Some problems were encountered while building the effective model
> for org.apache.hbase:hbase-thrift:jar:3.0.0-SNAPSHOT
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
> be unique: org.slf4j:slf4j-api:jar -> duplicate declaration of version (?) @
> org.apache.hbase:hbase-thrift:[unknown-version],
> /Users/jan/Documents/Projects/github/hbase/hbase-thrift/pom.xml, line 250,
> column 17
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> {code}
> One should be removed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19715) Fix timing out test TestMultiRespectsLimits
[ https://issues.apache.org/jira/browse/HBASE-19715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315075#comment-16315075 ] Appy commented on HBASE-19715: -- [~chia7712] can you please provide me a quick patch with what you thinking? I can profile it for memory just like above analysis. > Fix timing out test TestMultiRespectsLimits > --- > > Key: HBASE-19715 > URL: https://issues.apache.org/jira/browse/HBASE-19715 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: failued.txt, passed.txt, screenshot-1.png, > screenshot-2.png, screenshot-3.png, screenshot-4.png > > > !screenshot-1.png|width=800px! > Attached logs for both cases, when it passes and fails. > Link (temporary) to logs: > passed: > http://104.198.223.121:8080/job/HBase-Flaky-Tests/33449/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestMultiRespectsLimits-output.txt/*view*/ > failed: > http://104.198.223.121:8080/job/HBase-Flaky-Tests/33455/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestMultiRespectsLimits-output.txt/*view*/ > Correlating across more runs, whenever the tests passes, it does so within > 10-30sec of 3min deadline for medium tests. > So i think we can make it pass by just increasing the timeout. > But I'm a bit skeptical after seeing all those long GC pauses (10sec +) in > the log. Test code doesn't seem to be doing anything that intensive. Are we > mismanaging the memory somewhere? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19397) Design procedures for ReplicationManager to notify peer change event from master
[
https://issues.apache.org/jira/browse/HBASE-19397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315022#comment-16315022
]
Duo Zhang commented on HBASE-19397:
---
Ping [~stack] [~anoopsamjohn]. I've already started a vote thread.
I've been running UTs locally several times. There are failed UTs but it is not
likely to be caused by the modification here. Will try to run with forkCount=1
and exclude all the flakey UTs(copy from the pre commit command line) and see
what's going on.
Thanks.
> Design procedures for ReplicationManager to notify peer change event from
> master
> -
>
> Key: HBASE-19397
> URL: https://issues.apache.org/jira/browse/HBASE-19397
> Project: HBase
> Issue Type: New Feature
> Components: proc-v2, Replication
>Reporter: Zheng Hu
>Assignee: Zheng Hu
> Attachments: HBASE-19397-branch-2.patch, HBASE-19397-master-v1.patch,
> HBASE-19397-master-v1.patch, HBASE-19397-master.patch
>
>
> After we store peer states / peer queues information into hbase table, RS
> can not track peer config change by adding watcher znode.
> So we need design procedures for ReplicationManager to notify peer change
> event. the replication rpc interfaces which may be implemented by
> procedures are following:
> {code}
> 1. addReplicationPeer
> 2. removeReplicationPeer
> 3. enableReplicationPeer
> 4. disableReplicationPeer
> 5. updateReplicationPeerConfig
> {code}
> BTW, our RS states will still be store in zookeeper, so when RS crash, the
> tracker which will trigger to transfer queues of crashed RS will still be a
> Zookeeper Tracker. we need NOT implement that by procedures.
> As we will release 2.0 in next weeks, and the HBASE-15867 can not be
> resolved before the release, so I'd prefer to create a new feature branch
> for HBASE-15867.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19603) Fix Checkstyle errors in hbase-replication
[ https://issues.apache.org/jira/browse/HBASE-19603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314963#comment-16314963 ] Hudson commented on HBASE-19603: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4356 (See [https://builds.apache.org/job/HBase-Trunk_matrix/4356/]) HBASE-19603 Fixed Checkstyle errors in hbase-replication and enabled (jan.hentschel: rev 228d7a5a46aaffc866dd054f8ebb2ecbd0f3b867) * (edit) hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ReplicationQueuesZKImpl.java * (edit) hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ReplicationQueuesClientZKImpl.java * (edit) hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ReplicationTracker.java * (edit) hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ReplicationPeers.java * (edit) hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ReplicationQueuesClient.java * (edit) hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ReplicationQueues.java * (edit) hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ReplicationPeersZKImpl.java * (edit) hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ReplicationQueueInfo.java * (edit) hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ReplicationStateZKBase.java * (edit) hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ReplicationFactory.java * (edit) hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ReplicationTrackerZKImpl.java * (edit) hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ReplicationTableBase.java * (edit) hbase-replication/pom.xml * (edit) hbase-replication/src/main/java/org/apache/hadoop/hbase/replication/ReplicationPeerZKImpl.java > Fix Checkstyle errors in hbase-replication > -- > > Key: HBASE-19603 > URL: https://issues.apache.org/jira/browse/HBASE-19603 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Jan Hentschel >Assignee: Jan Hentschel >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-19603.master.001.patch, > HBASE-19603.master.002.patch, HBASE-19603.master.003.patch, > HBASE-19603.master.004.patch > > > Fix the remaining Checkstyle errors in the *hbase-replication* module and > enable Checkstyle to fail on violations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19713) Enable TestInterfaceAudienceAnnotations
[
https://issues.apache.org/jira/browse/HBASE-19713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314949#comment-16314949
]
Hadoop QA commented on HBASE-19713:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
52s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 12 new or modified test
files. {color} |
|| || || || {color:brown} branch-2 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
12s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
34s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
11s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
37s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 8m
29s{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
6s{color} | {color:green} branch-2 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
11s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s{color} | {color:green} The patch hbase-common passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s{color} | {color:green} The patch hbase-hadoop-compat passed checkstyle
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
29s{color} | {color:green} hbase-client: The patch generated 0 new + 66
unchanged - 3 fixed = 66 total (was 69) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s{color} | {color:green} The patch hbase-zookeeper passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s{color} | {color:green} The patch hbase-replication passed checkstyle
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
12s{color} | {color:green} hbase-http: The patch generated 0 new + 27 unchanged
- 4 fixed = 27 total (was 31) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
16s{color} | {color:red} hbase-server: The patch generated 1 new + 912
unchanged - 19 fixed = 913 total (was 931) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
19s{color} | {color:green} hbase-mapreduce: The patch generated 0 new + 141
unchanged - 1 fixed = 141 total (was 142) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
28s{color} | {color:green} The patch hbase-thrift passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s{color} | {color:green} hbase-endpoint: The patch generated 0 new + 15
unchanged - 2 fixed = 15 total (was 17) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
20s{color} | {color:green} The patch hbase-it passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
15s{color} | {color:green} The patch hbase-rest passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s{color} | {color:green} The patch hbase-examples passed checkstyle {color} |
|
[jira] [Commented] (HBASE-19715) Fix timing out test TestMultiRespectsLimits
[
https://issues.apache.org/jira/browse/HBASE-19715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314915#comment-16314915
]
Chia-Ping Tsai commented on HBASE-19715:
Seems the cost of retry is prohibitive. I run the
TestMultiRespectsLimits#testMultiLimits with jmc. The observation, which is
different from yours, is that building the exception create lots of char
arrays. The {{sizeIOE}} won't be changed after initializing so we can cache the
{{pair}} in order to avoid building the proto exception repeatedly.
{code:title=RsRpcService#doNonAtomicRegionMutation}
// We're storing the exception since the exception and reason string
won't
// change after the response size limit is reached.
if (sizeIOE == null ) {
// We don't need the stack un-winding do don't throw the exception.
// Throwing will kill the JVM's JIT.
//
// Instead just create the exception and then store it.
sizeIOE = new MultiActionResultTooLarge("Max size exceeded"
+ " CellSize: " + context.getResponseCellSize()
+ " BlockSize: " + context.getResponseBlockSize());
// Only report the exception once since there's only one request
that
// caused the exception. Otherwise this number will dominate the
exceptions count.
rpcServer.getMetrics().exception(sizeIOE);
}
// Now that there's an exception is known to be created
// use it for the response.
//
// This will create a copy in the builder.
hasResultOrException = true;
NameBytesPair pair = ResponseConverter.buildException(sizeIOE);
{code}
> Fix timing out test TestMultiRespectsLimits
> ---
>
> Key: HBASE-19715
> URL: https://issues.apache.org/jira/browse/HBASE-19715
> Project: HBase
> Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
> Attachments: failued.txt, passed.txt, screenshot-1.png,
> screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> !screenshot-1.png|width=800px!
> Attached logs for both cases, when it passes and fails.
> Link (temporary) to logs:
> passed:
> http://104.198.223.121:8080/job/HBase-Flaky-Tests/33449/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestMultiRespectsLimits-output.txt/*view*/
> failed:
> http://104.198.223.121:8080/job/HBase-Flaky-Tests/33455/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestMultiRespectsLimits-output.txt/*view*/
> Correlating across more runs, whenever the tests passes, it does so within
> 10-30sec of 3min deadline for medium tests.
> So i think we can make it pass by just increasing the timeout.
> But I'm a bit skeptical after seeing all those long GC pauses (10sec +) in
> the log. Test code doesn't seem to be doing anything that intensive. Are we
> mismanaging the memory somewhere?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19723) hbase-thrift declares slf4j-api twice
[
https://issues.apache.org/jira/browse/HBASE-19723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314914#comment-16314914
]
Ted Yu commented on HBASE-19723:
+1
> hbase-thrift declares slf4j-api twice
> -
>
> Key: HBASE-19723
> URL: https://issues.apache.org/jira/browse/HBASE-19723
> Project: HBase
> Issue Type: Improvement
> Components: Thrift
>Affects Versions: 3.0.0
>Reporter: Jan Hentschel
>Assignee: Jan Hentschel
>Priority: Trivial
> Attachments: HBASE-19723.master.001.patch
>
>
> Currently *hbase-thrift* declares the dependency {{slf4j-api}} twice
> resulting in the following warning
> {code}
> [WARNING] Some problems were encountered while building the effective model
> for org.apache.hbase:hbase-thrift:jar:3.0.0-SNAPSHOT
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
> be unique: org.slf4j:slf4j-api:jar -> duplicate declaration of version (?) @
> org.apache.hbase:hbase-thrift:[unknown-version],
> /Users/jan/Documents/Projects/github/hbase/hbase-thrift/pom.xml, line 250,
> column 17
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> {code}
> One should be removed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19723) hbase-thrift declares slf4j-api twice
[
https://issues.apache.org/jira/browse/HBASE-19723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314913#comment-16314913
]
Hadoop QA commented on HBASE-19723:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
49s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 9m
27s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
20s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
38s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
19m 12s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
20s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
51s{color} | {color:green} hbase-thrift in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
9s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 38m 20s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19723 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12904958/HBASE-19723.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit shadedjars hadoopcheck
xml compile |
| uname | Linux 870f320001c3 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 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 / 228d7a5a46 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/10919/testReport/ |
| modules | C: hbase-thrift U: hbase-thrift |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10919/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> hbase-thrift declares slf4j-api twice
> -
>
> Key: HBASE-19723
> URL: https://issues.apache.org/jira/browse/HBASE-19723
> Project: HBase
> Issue Type: Improvement
> Components: Thrift
>Affects Versions: 3.0.0
>Reporter: Jan Hentschel
>Assignee: Jan Hentschel
>Priority: Trivial
> Attachments: HBASE-19723.master.001.patch
>
>
> Currently *hbase-thrift* declares the dependency {{slf4j-api}} twice
>
[jira] [Commented] (HBASE-19471) Fix remaining Checkstyle errors in hbase-thrift
[
https://issues.apache.org/jira/browse/HBASE-19471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314911#comment-16314911
]
Hadoop QA commented on HBASE-19471:
---
| (/) *{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:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 6 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
24s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
1s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
35s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s{color} | {color:green} The patch hbase-checkstyle passed checkstyle {color}
|
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
36s{color} | {color:green} hbase-thrift: The patch generated 0 new + 0
unchanged - 447 fixed = 0 total (was 447) {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
3s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
27s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
23m 44s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
9s{color} | {color:green} hbase-checkstyle in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
50s{color} | {color:green} hbase-thrift in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 49m 20s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19471 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12904957/HBASE-19471.master.002.patch
|
| Optional Tests | asflicense javac javadoc unit xml shadedjars
hadoopcheck compile findbugs hbaseanti checkstyle |
| uname | Linux ebcf6fdc0bbb 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19
15:49:21 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Updated] (HBASE-19723) hbase-thrift declares slf4j-api twice
[
https://issues.apache.org/jira/browse/HBASE-19723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Hentschel updated HBASE-19723:
--
Status: Patch Available (was: In Progress)
> hbase-thrift declares slf4j-api twice
> -
>
> Key: HBASE-19723
> URL: https://issues.apache.org/jira/browse/HBASE-19723
> Project: HBase
> Issue Type: Improvement
> Components: Thrift
>Affects Versions: 3.0.0
>Reporter: Jan Hentschel
>Assignee: Jan Hentschel
>Priority: Trivial
> Attachments: HBASE-19723.master.001.patch
>
>
> Currently *hbase-thrift* declares the dependency {{slf4j-api}} twice
> resulting in the following warning
> {code}
> [WARNING] Some problems were encountered while building the effective model
> for org.apache.hbase:hbase-thrift:jar:3.0.0-SNAPSHOT
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
> be unique: org.slf4j:slf4j-api:jar -> duplicate declaration of version (?) @
> org.apache.hbase:hbase-thrift:[unknown-version],
> /Users/jan/Documents/Projects/github/hbase/hbase-thrift/pom.xml, line 250,
> column 17
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> {code}
> One should be removed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19723) hbase-thrift declares slf4j-api twice
[
https://issues.apache.org/jira/browse/HBASE-19723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Hentschel updated HBASE-19723:
--
Attachment: HBASE-19723.master.001.patch
> hbase-thrift declares slf4j-api twice
> -
>
> Key: HBASE-19723
> URL: https://issues.apache.org/jira/browse/HBASE-19723
> Project: HBase
> Issue Type: Improvement
> Components: Thrift
>Affects Versions: 3.0.0
>Reporter: Jan Hentschel
>Assignee: Jan Hentschel
>Priority: Trivial
> Attachments: HBASE-19723.master.001.patch
>
>
> Currently *hbase-thrift* declares the dependency {{slf4j-api}} twice
> resulting in the following warning
> {code}
> [WARNING] Some problems were encountered while building the effective model
> for org.apache.hbase:hbase-thrift:jar:3.0.0-SNAPSHOT
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
> be unique: org.slf4j:slf4j-api:jar -> duplicate declaration of version (?) @
> org.apache.hbase:hbase-thrift:[unknown-version],
> /Users/jan/Documents/Projects/github/hbase/hbase-thrift/pom.xml, line 250,
> column 17
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> {code}
> One should be removed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Work started] (HBASE-19723) hbase-thrift declares slf4j-api twice
[
https://issues.apache.org/jira/browse/HBASE-19723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HBASE-19723 started by Jan Hentschel.
-
> hbase-thrift declares slf4j-api twice
> -
>
> Key: HBASE-19723
> URL: https://issues.apache.org/jira/browse/HBASE-19723
> Project: HBase
> Issue Type: Improvement
> Components: Thrift
>Affects Versions: 3.0.0
>Reporter: Jan Hentschel
>Assignee: Jan Hentschel
>Priority: Trivial
>
> Currently *hbase-thrift* declares the dependency {{slf4j-api}} twice
> resulting in the following warning
> {code}
> [WARNING] Some problems were encountered while building the effective model
> for org.apache.hbase:hbase-thrift:jar:3.0.0-SNAPSHOT
> [WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
> be unique: org.slf4j:slf4j-api:jar -> duplicate declaration of version (?) @
> org.apache.hbase:hbase-thrift:[unknown-version],
> /Users/jan/Documents/Projects/github/hbase/hbase-thrift/pom.xml, line 250,
> column 17
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> {code}
> One should be removed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19723) hbase-thrift declares slf4j-api twice
Jan Hentschel created HBASE-19723:
-
Summary: hbase-thrift declares slf4j-api twice
Key: HBASE-19723
URL: https://issues.apache.org/jira/browse/HBASE-19723
Project: HBase
Issue Type: Improvement
Components: Thrift
Affects Versions: 3.0.0
Reporter: Jan Hentschel
Assignee: Jan Hentschel
Priority: Trivial
Currently *hbase-thrift* declares the dependency {{slf4j-api}} twice resulting
in the following warning
{code}
[WARNING] Some problems were encountered while building the effective model for
org.apache.hbase:hbase-thrift:jar:3.0.0-SNAPSHOT
[WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
be unique: org.slf4j:slf4j-api:jar -> duplicate declaration of version (?) @
org.apache.hbase:hbase-thrift:[unknown-version],
/Users/jan/Documents/Projects/github/hbase/hbase-thrift/pom.xml, line 250,
column 17
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
{code}
One should be removed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19471) Fix remaining Checkstyle errors in hbase-thrift
[ https://issues.apache.org/jira/browse/HBASE-19471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Hentschel updated HBASE-19471: -- Attachment: HBASE-19471.master.002.patch > Fix remaining Checkstyle errors in hbase-thrift > --- > > Key: HBASE-19471 > URL: https://issues.apache.org/jira/browse/HBASE-19471 > Project: HBase > Issue Type: Sub-task > Components: Thrift >Reporter: Jan Hentschel >Assignee: Jan Hentschel >Priority: Minor > Attachments: HBASE-19471.master.001.patch, > HBASE-19471.master.002.patch > > > Some Checkstyle errors are left in the *hbase-thrift* module and should be > fixed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19721) Unnecessary stubbings detected in test class: TestReversedScannerCallable
[
https://issues.apache.org/jira/browse/HBASE-19721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314888#comment-16314888
]
Hudson commented on HBASE-19721:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4355 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/4355/])
HBASE-19721 Unnecessary stubbings in TestReversedScannerCallable (stack: rev
022a348d612b4471877012ca8a0a114ba222f18e)
* (edit)
hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestReversedScannerCallable.java
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> -
>
> Key: HBASE-19721
> URL: https://issues.apache.org/jira/browse/HBASE-19721
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Jean-Marc Spaggiari
>Assignee: Mike Drob
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19721.patch
>
>
> Found by JMS on the mailing list:
> {noformat}
> ---
> Test set: org.apache.hadoop.hbase.client.TestReversedScannerCallable
> ---
> Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.515 s <<<
> FAILURE! - in org.apache.hadoop.hbase.client.TestReversedScannerCallable
> unnecessary Mockito
> stubbings(org.apache.hadoop.hbase.client.TestReversedScannerCallable) Time
> elapsed: 0.014 s <<< ERROR!
> org.mockito.exceptions.misusing.UnnecessaryStubbingException:
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> Clean & maintainable test code requires zero unnecessary code.
> Following stubbings are unnecessary (click to navigate to relevant line of
> code):
> 1. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:66)
> 2. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:68)
> Please remove unnecessary stubbings. More info: javadoc for
> UnnecessaryStubbingException class.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19714) `status 'detailed'` invokes nonexistent "getRegionsInTransition" method on ClusterStatus
[
https://issues.apache.org/jira/browse/HBASE-19714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314887#comment-16314887
]
Hudson commented on HBASE-19714:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4355 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/4355/])
HBASE-19714 Fix broken status-detailed (stack: rev
ea819d1733d94cd357177ca1070f5c80b0321d03)
* (edit) hbase-shell/src/main/ruby/hbase/admin.rb
* (edit) hbase-shell/src/test/ruby/hbase/admin_test.rb
> `status 'detailed'` invokes nonexistent "getRegionsInTransition" method on
> ClusterStatus
>
>
> Key: HBASE-19714
> URL: https://issues.apache.org/jira/browse/HBASE-19714
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19714.001.branch-2.patch,
> HBASE-19714.002.branch-2.patch
>
>
> {noformat}
> hbase(main):003:0> status 'detailed'
> version 2.0.0-beta-1
> ERROR: undefined method `getRegionsInTransition' for
> #
> Did you mean? get_region_states_in_transition
>getRegionStatesInTransition
> Show cluster status. Can be 'summary', 'simple', 'detailed', or
> 'replication'. The
> default is 'summary'. Examples:
> hbase> status
> hbase> status 'simple'
> hbase> status 'summary'
> hbase> status 'detailed'
> hbase> status 'replication'
> hbase> status 'replication', 'source'
> hbase> status 'replication', 'sink'
> Took 0.1814 seconds
> {noformat}
> Looks like the method is now {{getRegionStatesInTransition}} instead of
> {{getRegionsInTransition}}.
> FYI [~stack].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19722) Implement a meta query statistics metrics source
[
https://issues.apache.org/jira/browse/HBASE-19722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314878#comment-16314878
]
Andrew Purtell commented on HBASE-19722:
Comment from [~stack] on parent:
{quote}
Need this. Currently scraping and dumping to tsdb. Next was how to integrate.
You are ahead. Was trying to figure list of questions report would answer.
Histograms.
First questions we had were whether scan or random get (if latter then the
indexed block fix would help) and then source of loading.
{quote}
> Implement a meta query statistics metrics source
>
>
> Key: HBASE-19722
> URL: https://issues.apache.org/jira/browse/HBASE-19722
> Project: HBase
> Issue Type: Sub-task
>Reporter: Andrew Purtell
>
> Implement a meta query statistics metrics source, created whenever a
> regionserver starts hosting meta, removed when meta hosting moves. Provide
> views on top tables by request counts, top meta rowkeys by request count, top
> clients making requests by their hostname.
> Can be implemented as a coprocessor.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19603) Fix Checkstyle errors in hbase-replication
[ https://issues.apache.org/jira/browse/HBASE-19603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Hentschel updated HBASE-19603: -- Resolution: Fixed Fix Version/s: 3.0.0 Status: Resolved (was: Patch Available) > Fix Checkstyle errors in hbase-replication > -- > > Key: HBASE-19603 > URL: https://issues.apache.org/jira/browse/HBASE-19603 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Jan Hentschel >Assignee: Jan Hentschel >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-19603.master.001.patch, > HBASE-19603.master.002.patch, HBASE-19603.master.003.patch, > HBASE-19603.master.004.patch > > > Fix the remaining Checkstyle errors in the *hbase-replication* module and > enable Checkstyle to fail on violations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19702) Improve RSGroupInfo constructors
[
https://issues.apache.org/jira/browse/HBASE-19702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314873#comment-16314873
]
Chia-Ping Tsai commented on HBASE-19702:
Could we do the clone here? RSGroupInfo has many setter which can change the
collection internally. Hence, the patch will disable RSGroupInfo to accept the
immutable collection.
{code}
-this.servers = servers == null? new TreeSet<>(): servers;
-this.servers.addAll(servers);
-this.tables = new TreeSet<>(tables);
+this.servers = (servers == null) ? new TreeSet<>() : servers;
+this.tables = (tables == null) ? new TreeSet<>() : tables;
{code}
> Improve RSGroupInfo constructors
>
>
> Key: HBASE-19702
> URL: https://issues.apache.org/jira/browse/HBASE-19702
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19702.master.000.patch
>
>
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfo.java|borderStyle=solid}
> RSGroupInfo(String name, SortedSet servers, SortedSet
> tables) {
> this.name = name;
> this.servers = servers == null? new TreeSet<>(): servers;
> this.servers.addAll(servers);
> this.tables = new TreeSet<>(tables);
> }
> {code}
> 2 improvements could be made:
> * When servers is not null, addAll(servers) tries to add all items in servers
> again. Seems not needed
> * new TreeSet<>(tables) has no null check on tables. The constructor of
> TreeSet does not do the null check either. It leads to NullPointerException
> if tables is null
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19722) Implement a meta query statistics metrics source
[ https://issues.apache.org/jira/browse/HBASE-19722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-19722: --- Description: Implement a meta query statistics metrics source, created whenever a regionserver starts hosting meta, removed when meta hosting moves. Provide views on top tables by request counts, top meta rowkeys by request count, top clients making requests by their hostname. Can be implemented as a coprocessor. was:Implement a meta query statistics metrics source, created whenever a regionserver starts hosting meta, removed when meta hosting moves. Provide views on top tables by request counts, top meta rowkeys by request count, top clients making requests by their hostname. > Implement a meta query statistics metrics source > > > Key: HBASE-19722 > URL: https://issues.apache.org/jira/browse/HBASE-19722 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell > > Implement a meta query statistics metrics source, created whenever a > regionserver starts hosting meta, removed when meta hosting moves. Provide > views on top tables by request counts, top meta rowkeys by request count, top > clients making requests by their hostname. > Can be implemented as a coprocessor. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19713) Enable TestInterfaceAudienceAnnotations
[ https://issues.apache.org/jira/browse/HBASE-19713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19713: --- Release Note: All classes, which are in a) hbase-server, b) hbase-client, c) hbase-replication, d) hbase-mapreduce, e) hbase-http, f) hbase-thrift, g) hbase-common, h) hbase-procedure, i) hbase-endpoint, j) hbase-rest, k) and hbase-zookeeper, must obey the following rules. 1. Public class MUST have the InterfaceAudience annotation 2. The class having InterfaceAudience.Public must NOT have InterfaceStability 3. The class having InterfaceAudience.LimitedPrivate MUST have InterfaceStability unless InterfaceAudience.LimitedPrivate consists of HBaseInterfaceAudience.Tools or HBaseInterfaceAudience.Config 4. All classes extending the o.a.h.u.Tool must have InterfaceAudience.LimitedPrivate and HBaseInterfaceAudience.Tools annotations 5. The Public class having InterfaceAudience.Public/LimitedPrivate CAN’T use protobuf object as parameter and return type unless the class is denoted as either HBaseInterfaceAudience.TOOLS or HBaseInterfaceAudience.CONFIG Add two annotations 1. HBaseInterfaceAudience.Hive - The TokenUtil is exposed as Public for Hive 2. HBaseInterfaceAudience.ProtobufExposed- used to denote the classes which are allowed to use protobuf object in return type or parameter TestInterfaceAudienceAnnotations is moved to hbase-example module since TestInterfaceAudienceAnnotations have to "see" other modules from the classpath. The hbase-example module can add dependencies freely. was: All classes, which are in a) hbase-server, b) hbase-client, c) hbase-replication, d) hbase-mapreduce, e) hbase-http, f) hbase-thrift, g) hbase-common, h) hbase-procedure, i) hbase-endpoint, j) hbase-rest, k) and hbase-zookeeper, must obey the following rules. 1. Public class MUST have the InterfaceAudience annotation 2. The class having InterfaceAudience.Public must NOT have InterfaceStability 3. The class having InterfaceAudience.LimitedPrivate MUST have InterfaceStability unless InterfaceAudience.LimitedPrivate consists of HBaseInterfaceAudience.Tools or HBaseInterfaceAudience.Config 4. All classes extending the o.a.h.u.Tool must have InterfaceAudience.LimitedPrivate and HBaseInterfaceAudience.Tools annotations 5. The Public class having InterfaceAudience.Public/LimitedPrivate CAN’T use protobuf object as parameter and return type unless the class is denoted as either HBaseInterfaceAudience.TOOLS or HBaseInterfaceAudience.CONFIG Add two annotations 1. HBaseInterfaceAudience.Hive - The TokenUtil is exposed as Public for Hive 2. HBaseInterfaceAudience.ProtobufExposed- used to denote the classes which are allowed to use protobuf object in return type or parameter TestInterfaceAudienceAnnotations is moved to hbase-example module since TestInterfaceAudienceAnnotations have to "see" other modules in the classpath. The hbase-example module can add dependencies freely. > Enable TestInterfaceAudienceAnnotations > --- > > Key: HBASE-19713 > URL: https://issues.apache.org/jira/browse/HBASE-19713 > Project: HBase > Issue Type: Task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-19713.branch-2.v0.patch, HBASE-19713.v0.patch > > > Make sure TestInterfaceAudienceAnnotations pass before 2.0 release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19713) Enable TestInterfaceAudienceAnnotations
[ https://issues.apache.org/jira/browse/HBASE-19713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19713: --- Release Note: All classes, which are in a) hbase-server, b) hbase-client, c) hbase-replication, d) hbase-mapreduce, e) hbase-http, f) hbase-thrift, g) hbase-common, h) hbase-procedure, i) hbase-endpoint, j) hbase-rest, k) and hbase-zookeeper, must obey the following rules. 1. Public class MUST have the InterfaceAudience annotation 2. The class having InterfaceAudience.Public must NOT have InterfaceStability 3. The class having InterfaceAudience.LimitedPrivate MUST have InterfaceStability unless InterfaceAudience.LimitedPrivate consists of HBaseInterfaceAudience.Tools or HBaseInterfaceAudience.Config 4. All classes extending the o.a.h.u.Tool must have InterfaceAudience.LimitedPrivate and HBaseInterfaceAudience.Tools annotations 5. The Public class having InterfaceAudience.Public/LimitedPrivate CAN’T use protobuf object as parameter and return type unless the class is denoted as either HBaseInterfaceAudience.TOOLS or HBaseInterfaceAudience.CONFIG Add two annotations 1. HBaseInterfaceAudience.Hive - The TokenUtil is exposed as Public for Hive 2. HBaseInterfaceAudience.ProtobufExposed- used to denote the classes which are allowed to use protobuf object in return type or parameter TestInterfaceAudienceAnnotations is moved to hbase-example module since TestInterfaceAudienceAnnotations have to "see" other modules in the classpath. The hbase-example module can add dependencies freely. was: All classes, which are in a) hbase-server, b) hbase-client, c) hbase-replication, d) hbase-mapreduce, e) hbase-http, f) hbase-thrift, g) hbase-common, h) hbase-procedure, i) hbase-endpoint, j) hbase-rest, k) and hbase-zookeeper, must obey the following rules. 1. Public class MUST have the InterfaceAudience annotation 2. The class having InterfaceAudience.Public must NOT have InterfaceStability 3. The class having InterfaceAudience.LimitedPrivate MUST have InterfaceStability unless InterfaceAudience.LimitedPrivate consists of HBaseInterfaceAudience.Tools or HBaseInterfaceAudience.Config 4. All classes extending the o.a.h.u.Tool must have InterfaceAudience.LimitedPrivate and HBaseInterfaceAudience.Tools annotations 5. The Public class having InterfaceAudience.Public/LimitedPrivate CAN’T use protobuf object as parameter and return type unless the class is denoted as either HBaseInterfaceAudience.TOOLS or HBaseInterfaceAudience.CONFIG Add two annotations 1. HBaseInterfaceAudience.Hive - The TokenUtil is exposed as Public for Hive 2. HBaseInterfaceAudience.ProtobufExposed- used to denote the classes which are allowed to use protobuf object in return type or parameter > Enable TestInterfaceAudienceAnnotations > --- > > Key: HBASE-19713 > URL: https://issues.apache.org/jira/browse/HBASE-19713 > Project: HBase > Issue Type: Task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-19713.branch-2.v0.patch, HBASE-19713.v0.patch > > > Make sure TestInterfaceAudienceAnnotations pass before 2.0 release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-11062) htop
[ https://issues.apache.org/jira/browse/HBASE-11062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314856#comment-16314856 ] stack commented on HBASE-11062: --- Need this. Currently scraping and dumping to tsdb. Next was how to integrate. You are ahead. Was trying to figure list of questions report would answer. Histograms. What you seeing for load? First questions we had were whether scan or random get (if latter then the indexed block fix would help) and then source of loading. Good stuff andy > htop > > > Key: HBASE-11062 > URL: https://issues.apache.org/jira/browse/HBASE-11062 > Project: HBase > Issue Type: New Feature >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Labels: beginner > > A top-like monitor could be useful for testing, debugging, operations of > clusters of moderate size, and possibly for diagnosing issues in large > clusters. > Consider a curses interface like the one presented by atop > (http://www.atoptool.nl/images/screenshots/genericw.png) - with aggregate > metrics collected over a monitoring interval in the upper portion of the > pane, and a listing of discrete measurements sorted and filtered by various > criteria in the bottom part of the pane. One might imagine a cluster overview > with cluster aggregate metrics above and a list of regionservers sorted by > utilization below; and a regionserver view with process metrics above and a > list of metrics by operation type below, or a list of client connections, or > a list of threads, sorted by utilization, throughput, or latency. > Generically 'htop' is taken but would be distinctive in the HBase context, a > utility org.apache.hadoop.hbase.HTop > No need necessarily for a curses interface. Could be an external monitor with > a web front end as has been discussed before. I do like the idea of a process > that runs in a terminal because I interact with dev and test HBase clusters > exclusively by SSH. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19722) Implement a meta query statistics metrics source
Andrew Purtell created HBASE-19722: -- Summary: Implement a meta query statistics metrics source Key: HBASE-19722 URL: https://issues.apache.org/jira/browse/HBASE-19722 Project: HBase Issue Type: Sub-task Reporter: Andrew Purtell Implement a meta query statistics metrics source, created whenever a regionserver starts hosting meta, removed when meta hosting moves. Provide views on top tables by request counts, top meta rowkeys by request count, top clients making requests by their hostname. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19722) Implement a meta query statistics metrics source
[ https://issues.apache.org/jira/browse/HBASE-19722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314842#comment-16314842 ] Andrew Purtell commented on HBASE-19722: While debugging elevated meta query rates we've noticed how clunky it is to do that right now. In order to find top-N accesses by client identity or by table name you have to toggle RpcServer to TRACE (only for a short time!), scrape the resulting log output, extract via regex, rinse and repeat. It becomes apparent a special set of metrics for the meta region, counting queries for particular tables and by client identity, would be useful. > Implement a meta query statistics metrics source > > > Key: HBASE-19722 > URL: https://issues.apache.org/jira/browse/HBASE-19722 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell > > Implement a meta query statistics metrics source, created whenever a > regionserver starts hosting meta, removed when meta hosting moves. Provide > views on top tables by request counts, top meta rowkeys by request count, top > clients making requests by their hostname. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-11062) htop
[ https://issues.apache.org/jira/browse/HBASE-11062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314835#comment-16314835 ] Andrew Purtell commented on HBASE-11062: While debugging elevated meta query rates we've noticed how clunky it is to do that right now. In order to find top-N accesses by client identity or by table name you have to toggle RpcServer to TRACE (only for a short time!), scrape the resulting log output, extract via regex, rinse and repeat. It becomes apparent a special set of metrics for the meta region, counting queries for particular tables and by client identity, would be useful. Although this JIRA is scoped to be a lot more than this, meta query statistics would be a good start. This doesn't require any cross cluster (partial) aggregation and communication. Whatever server hosting meta can create a special mbean for tracking meta request stats. This information would be picked up by whatever monitoring solution is already in place. I'll file a subtask for this. > htop > > > Key: HBASE-11062 > URL: https://issues.apache.org/jira/browse/HBASE-11062 > Project: HBase > Issue Type: New Feature >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Labels: beginner > > A top-like monitor could be useful for testing, debugging, operations of > clusters of moderate size, and possibly for diagnosing issues in large > clusters. > Consider a curses interface like the one presented by atop > (http://www.atoptool.nl/images/screenshots/genericw.png) - with aggregate > metrics collected over a monitoring interval in the upper portion of the > pane, and a listing of discrete measurements sorted and filtered by various > criteria in the bottom part of the pane. One might imagine a cluster overview > with cluster aggregate metrics above and a list of regionservers sorted by > utilization below; and a regionserver view with process metrics above and a > list of metrics by operation type below, or a list of client connections, or > a list of threads, sorted by utilization, throughput, or latency. > Generically 'htop' is taken but would be distinctive in the HBase context, a > utility org.apache.hadoop.hbase.HTop > No need necessarily for a curses interface. Could be an external monitor with > a web front end as has been discussed before. I do like the idea of a process > that runs in a terminal because I interact with dev and test HBase clusters > exclusively by SSH. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19713) Enable TestInterfaceAudienceAnnotations
[ https://issues.apache.org/jira/browse/HBASE-19713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19713: --- Attachment: HBASE-19713.branch-2.v0.patch > Enable TestInterfaceAudienceAnnotations > --- > > Key: HBASE-19713 > URL: https://issues.apache.org/jira/browse/HBASE-19713 > Project: HBase > Issue Type: Task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-19713.branch-2.v0.patch, HBASE-19713.v0.patch > > > Make sure TestInterfaceAudienceAnnotations pass before 2.0 release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19713) Enable TestInterfaceAudienceAnnotations
[ https://issues.apache.org/jira/browse/HBASE-19713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19713: --- Release Note: All classes, which are in a) hbase-server, b) hbase-client, c) hbase-replication, d) hbase-mapreduce, e) hbase-http, f) hbase-thrift, g) hbase-common, h) hbase-procedure, i) hbase-endpoint, j) hbase-rest, k) and hbase-zookeeper, must obey the following rules. 1. Public class MUST have the InterfaceAudience annotation 2. The class having InterfaceAudience.Public must NOT have InterfaceStability 3. The class having InterfaceAudience.LimitedPrivate MUST have InterfaceStability unless InterfaceAudience.LimitedPrivate consists of HBaseInterfaceAudience.Tools or HBaseInterfaceAudience.Config 4. All classes extending the o.a.h.u.Tool must have InterfaceAudience.LimitedPrivate and HBaseInterfaceAudience.Tools annotations 5. The Public class having InterfaceAudience.Public/LimitedPrivate CAN’T use protobuf object as parameter and return type unless the class is denoted as either HBaseInterfaceAudience.TOOLS or HBaseInterfaceAudience.CONFIG Add two annotations 1. HBaseInterfaceAudience.Hive - The TokenUtil is exposed as Public for Hive 2. HBaseInterfaceAudience.ProtobufExposed- used to denote the classes which are allowed to use protobuf object in return type or parameter > Enable TestInterfaceAudienceAnnotations > --- > > Key: HBASE-19713 > URL: https://issues.apache.org/jira/browse/HBASE-19713 > Project: HBase > Issue Type: Task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-19713.v0.patch > > > Make sure TestInterfaceAudienceAnnotations pass before 2.0 release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19713) Enable TestInterfaceAudienceAnnotations
[ https://issues.apache.org/jira/browse/HBASE-19713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19713: --- Attachment: HBASE-19713.v0.patch > Enable TestInterfaceAudienceAnnotations > --- > > Key: HBASE-19713 > URL: https://issues.apache.org/jira/browse/HBASE-19713 > Project: HBase > Issue Type: Task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-19713.v0.patch > > > Make sure TestInterfaceAudienceAnnotations pass before 2.0 release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19713) Enable TestInterfaceAudienceAnnotations
[ https://issues.apache.org/jira/browse/HBASE-19713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19713: --- Status: Patch Available (was: Open) > Enable TestInterfaceAudienceAnnotations > --- > > Key: HBASE-19713 > URL: https://issues.apache.org/jira/browse/HBASE-19713 > Project: HBase > Issue Type: Task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-19713.v0.patch > > > Make sure TestInterfaceAudienceAnnotations pass before 2.0 release. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19715) Fix timing out test TestMultiRespectsLimits
[ https://issues.apache.org/jira/browse/HBASE-19715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314712#comment-16314712 ] stack commented on HBASE-19715: --- [~appy] You want to be able to track the objects back to the reference holder. Might take a while with OQL. Commercial profilers allow you do this. The creation of AsyncReqestFutureImpl instances happens in one place only. Our AsyncProcess is awful in the number of threads it creates especially when blocked (another reason to more to async client basis). > Fix timing out test TestMultiRespectsLimits > --- > > Key: HBASE-19715 > URL: https://issues.apache.org/jira/browse/HBASE-19715 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: failued.txt, passed.txt, screenshot-1.png, > screenshot-2.png, screenshot-3.png, screenshot-4.png > > > !screenshot-1.png|width=800px! > Attached logs for both cases, when it passes and fails. > Link (temporary) to logs: > passed: > http://104.198.223.121:8080/job/HBase-Flaky-Tests/33449/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestMultiRespectsLimits-output.txt/*view*/ > failed: > http://104.198.223.121:8080/job/HBase-Flaky-Tests/33455/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.client.TestMultiRespectsLimits-output.txt/*view*/ > Correlating across more runs, whenever the tests passes, it does so within > 10-30sec of 3min deadline for medium tests. > So i think we can make it pass by just increasing the timeout. > But I'm a bit skeptical after seeing all those long GC pauses (10sec +) in > the log. Test code doesn't seem to be doing anything that intensive. Are we > mismanaging the memory somewhere? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19721) Unnecessary stubbings detected in test class: TestReversedScannerCallable
[
https://issues.apache.org/jira/browse/HBASE-19721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-19721:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: (was: 2.0.0-beta-2)
2.0.0-beta-1
Status: Resolved (was: Patch Available)
Pushed to master and branch-2. Thanks lads.
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> -
>
> Key: HBASE-19721
> URL: https://issues.apache.org/jira/browse/HBASE-19721
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Jean-Marc Spaggiari
>Assignee: Mike Drob
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19721.patch
>
>
> Found by JMS on the mailing list:
> {noformat}
> ---
> Test set: org.apache.hadoop.hbase.client.TestReversedScannerCallable
> ---
> Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.515 s <<<
> FAILURE! - in org.apache.hadoop.hbase.client.TestReversedScannerCallable
> unnecessary Mockito
> stubbings(org.apache.hadoop.hbase.client.TestReversedScannerCallable) Time
> elapsed: 0.014 s <<< ERROR!
> org.mockito.exceptions.misusing.UnnecessaryStubbingException:
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> Clean & maintainable test code requires zero unnecessary code.
> Following stubbings are unnecessary (click to navigate to relevant line of
> code):
> 1. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:66)
> 2. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:68)
> Please remove unnecessary stubbings. More info: javadoc for
> UnnecessaryStubbingException class.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19721) Unnecessary stubbings detected in test class: TestReversedScannerCallable
[
https://issues.apache.org/jira/browse/HBASE-19721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314691#comment-16314691
]
Hadoop QA commented on HBASE-19721:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s{color}
| {color:red} HBASE-19721 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.6.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-19721 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12904943/HBASE-19721.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10916/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> -
>
> Key: HBASE-19721
> URL: https://issues.apache.org/jira/browse/HBASE-19721
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Jean-Marc Spaggiari
>Assignee: Mike Drob
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19721.patch
>
>
> Found by JMS on the mailing list:
> {noformat}
> ---
> Test set: org.apache.hadoop.hbase.client.TestReversedScannerCallable
> ---
> Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.515 s <<<
> FAILURE! - in org.apache.hadoop.hbase.client.TestReversedScannerCallable
> unnecessary Mockito
> stubbings(org.apache.hadoop.hbase.client.TestReversedScannerCallable) Time
> elapsed: 0.014 s <<< ERROR!
> org.mockito.exceptions.misusing.UnnecessaryStubbingException:
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> Clean & maintainable test code requires zero unnecessary code.
> Following stubbings are unnecessary (click to navigate to relevant line of
> code):
> 1. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:66)
> 2. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:68)
> Please remove unnecessary stubbings. More info: javadoc for
> UnnecessaryStubbingException class.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19721) Unnecessary stubbings detected in test class: TestReversedScannerCallable
[
https://issues.apache.org/jira/browse/HBASE-19721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314687#comment-16314687
]
stack commented on HBASE-19721:
---
+1 I was going to push it. Trying to roll a new RC. Thanks lads.
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> -
>
> Key: HBASE-19721
> URL: https://issues.apache.org/jira/browse/HBASE-19721
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Jean-Marc Spaggiari
>Assignee: Mike Drob
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19721.patch
>
>
> Found by JMS on the mailing list:
> {noformat}
> ---
> Test set: org.apache.hadoop.hbase.client.TestReversedScannerCallable
> ---
> Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.515 s <<<
> FAILURE! - in org.apache.hadoop.hbase.client.TestReversedScannerCallable
> unnecessary Mockito
> stubbings(org.apache.hadoop.hbase.client.TestReversedScannerCallable) Time
> elapsed: 0.014 s <<< ERROR!
> org.mockito.exceptions.misusing.UnnecessaryStubbingException:
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> Clean & maintainable test code requires zero unnecessary code.
> Following stubbings are unnecessary (click to navigate to relevant line of
> code):
> 1. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:66)
> 2. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:68)
> Please remove unnecessary stubbings. More info: javadoc for
> UnnecessaryStubbingException class.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19721) Unnecessary stubbings detected in test class: TestReversedScannerCallable
[
https://issues.apache.org/jira/browse/HBASE-19721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314686#comment-16314686
]
Mike Drob commented on HBASE-19721:
---
I could reproduce this on both master and branch-2
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> -
>
> Key: HBASE-19721
> URL: https://issues.apache.org/jira/browse/HBASE-19721
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Jean-Marc Spaggiari
>Assignee: Mike Drob
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19721.patch
>
>
> Found by JMS on the mailing list:
> {noformat}
> ---
> Test set: org.apache.hadoop.hbase.client.TestReversedScannerCallable
> ---
> Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.515 s <<<
> FAILURE! - in org.apache.hadoop.hbase.client.TestReversedScannerCallable
> unnecessary Mockito
> stubbings(org.apache.hadoop.hbase.client.TestReversedScannerCallable) Time
> elapsed: 0.014 s <<< ERROR!
> org.mockito.exceptions.misusing.UnnecessaryStubbingException:
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> Clean & maintainable test code requires zero unnecessary code.
> Following stubbings are unnecessary (click to navigate to relevant line of
> code):
> 1. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:66)
> 2. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:68)
> Please remove unnecessary stubbings. More info: javadoc for
> UnnecessaryStubbingException class.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19721) Unnecessary stubbings detected in test class: TestReversedScannerCallable
[
https://issues.apache.org/jira/browse/HBASE-19721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated HBASE-19721:
--
Attachment: HBASE-19721.patch
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> -
>
> Key: HBASE-19721
> URL: https://issues.apache.org/jira/browse/HBASE-19721
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Jean-Marc Spaggiari
>Assignee: Mike Drob
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19721.patch
>
>
> Found by JMS on the mailing list:
> {noformat}
> ---
> Test set: org.apache.hadoop.hbase.client.TestReversedScannerCallable
> ---
> Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.515 s <<<
> FAILURE! - in org.apache.hadoop.hbase.client.TestReversedScannerCallable
> unnecessary Mockito
> stubbings(org.apache.hadoop.hbase.client.TestReversedScannerCallable) Time
> elapsed: 0.014 s <<< ERROR!
> org.mockito.exceptions.misusing.UnnecessaryStubbingException:
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> Clean & maintainable test code requires zero unnecessary code.
> Following stubbings are unnecessary (click to navigate to relevant line of
> code):
> 1. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:66)
> 2. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:68)
> Please remove unnecessary stubbings. More info: javadoc for
> UnnecessaryStubbingException class.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19721) Unnecessary stubbings detected in test class: TestReversedScannerCallable
[
https://issues.apache.org/jira/browse/HBASE-19721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated HBASE-19721:
--
Status: Patch Available (was: Open)
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> -
>
> Key: HBASE-19721
> URL: https://issues.apache.org/jira/browse/HBASE-19721
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Jean-Marc Spaggiari
>Assignee: Mike Drob
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19721.patch
>
>
> Found by JMS on the mailing list:
> {noformat}
> ---
> Test set: org.apache.hadoop.hbase.client.TestReversedScannerCallable
> ---
> Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.515 s <<<
> FAILURE! - in org.apache.hadoop.hbase.client.TestReversedScannerCallable
> unnecessary Mockito
> stubbings(org.apache.hadoop.hbase.client.TestReversedScannerCallable) Time
> elapsed: 0.014 s <<< ERROR!
> org.mockito.exceptions.misusing.UnnecessaryStubbingException:
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> Clean & maintainable test code requires zero unnecessary code.
> Following stubbings are unnecessary (click to navigate to relevant line of
> code):
> 1. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:66)
> 2. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:68)
> Please remove unnecessary stubbings. More info: javadoc for
> UnnecessaryStubbingException class.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19721) Unnecessary stubbings detected in test class: TestReversedScannerCallable
[
https://issues.apache.org/jira/browse/HBASE-19721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314679#comment-16314679
]
Jean-Marc Spaggiari commented on HBASE-19721:
-
FYI
jmspaggi@node8:~/hbase-test$ java -version
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> -
>
> Key: HBASE-19721
> URL: https://issues.apache.org/jira/browse/HBASE-19721
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Jean-Marc Spaggiari
>Assignee: Mike Drob
> Fix For: 2.0.0-beta-2
>
>
> Found by JMS on the mailing list:
> {noformat}
> ---
> Test set: org.apache.hadoop.hbase.client.TestReversedScannerCallable
> ---
> Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.515 s <<<
> FAILURE! - in org.apache.hadoop.hbase.client.TestReversedScannerCallable
> unnecessary Mockito
> stubbings(org.apache.hadoop.hbase.client.TestReversedScannerCallable) Time
> elapsed: 0.014 s <<< ERROR!
> org.mockito.exceptions.misusing.UnnecessaryStubbingException:
> Unnecessary stubbings detected in test class: TestReversedScannerCallable
> Clean & maintainable test code requires zero unnecessary code.
> Following stubbings are unnecessary (click to navigate to relevant line of
> code):
> 1. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:66)
> 2. -> at
> org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:68)
> Please remove unnecessary stubbings. More info: javadoc for
> UnnecessaryStubbingException class.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19721) Unnecessary stubbings detected in test class: TestReversedScannerCallable
Mike Drob created HBASE-19721:
-
Summary: Unnecessary stubbings detected in test class:
TestReversedScannerCallable
Key: HBASE-19721
URL: https://issues.apache.org/jira/browse/HBASE-19721
Project: HBase
Issue Type: Bug
Components: test
Reporter: Jean-Marc Spaggiari
Assignee: Mike Drob
Fix For: 2.0.0-beta-2
Found by JMS on the mailing list:
{noformat}
---
Test set: org.apache.hadoop.hbase.client.TestReversedScannerCallable
---
Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.515 s <<<
FAILURE! - in org.apache.hadoop.hbase.client.TestReversedScannerCallable
unnecessary Mockito
stubbings(org.apache.hadoop.hbase.client.TestReversedScannerCallable) Time
elapsed: 0.014 s <<< ERROR!
org.mockito.exceptions.misusing.UnnecessaryStubbingException:
Unnecessary stubbings detected in test class: TestReversedScannerCallable
Clean & maintainable test code requires zero unnecessary code.
Following stubbings are unnecessary (click to navigate to relevant line of
code):
1. -> at
org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:66)
2. -> at
org.apache.hadoop.hbase.client.TestReversedScannerCallable.setUp(TestReversedScannerCallable.java:68)
Please remove unnecessary stubbings. More info: javadoc for
UnnecessaryStubbingException class.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19714) `status 'detailed'` invokes nonexistent "getRegionsInTransition" method on ClusterStatus
[
https://issues.apache.org/jira/browse/HBASE-19714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-19714:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Pushed to branch-2 and master because trying to cut new RC. We'll probably
need this fix testing beta-1... Thanks [~elserj]
> `status 'detailed'` invokes nonexistent "getRegionsInTransition" method on
> ClusterStatus
>
>
> Key: HBASE-19714
> URL: https://issues.apache.org/jira/browse/HBASE-19714
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19714.001.branch-2.patch,
> HBASE-19714.002.branch-2.patch
>
>
> {noformat}
> hbase(main):003:0> status 'detailed'
> version 2.0.0-beta-1
> ERROR: undefined method `getRegionsInTransition' for
> #
> Did you mean? get_region_states_in_transition
>getRegionStatesInTransition
> Show cluster status. Can be 'summary', 'simple', 'detailed', or
> 'replication'. The
> default is 'summary'. Examples:
> hbase> status
> hbase> status 'simple'
> hbase> status 'summary'
> hbase> status 'detailed'
> hbase> status 'replication'
> hbase> status 'replication', 'source'
> hbase> status 'replication', 'sink'
> Took 0.1814 seconds
> {noformat}
> Looks like the method is now {{getRegionStatesInTransition}} instead of
> {{getRegionsInTransition}}.
> FYI [~stack].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19702) Improve RSGroupInfo constructors
[
https://issues.apache.org/jira/browse/HBASE-19702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314561#comment-16314561
]
Hadoop QA commented on HBASE-19702:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
54s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
59s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
15s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
31s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
19m 3s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
12s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 38m 59s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19702 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12904939/HBASE-19702.master.000.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 2bb466239c0f 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19
15:49:21 UTC 2017 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 / 54928ce3ea |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/10915/testReport/ |
| modules | C: hbase-common U: hbase-common |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10915/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> Improve RSGroupInfo constructors
>
>
> Key:
[jira] [Created] (HBASE-19720) Rename WALKey#getTabnename to WALKey#getTableName
Chia-Ping Tsai created HBASE-19720: -- Summary: Rename WALKey#getTabnename to WALKey#getTableName Key: HBASE-19720 URL: https://issues.apache.org/jira/browse/HBASE-19720 Project: HBase Issue Type: Task Reporter: Chia-Ping Tsai Assignee: Chia-Ping Tsai Fix For: 2.0.0 WALKey is denoted as LP so its naming should obey the common rule in our codebase. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19702) Improve RSGroupInfo constructors
[
https://issues.apache.org/jira/browse/HBASE-19702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314552#comment-16314552
]
Xiang Li commented on HBASE-19702:
--
Regarding using {{@NotNull}}, strongly agree. The following constructor does
need NotNull annotation set to RSGroupInfo src, as it reads src's fields
without null check.
{code}
public RSGroupInfo(RSGroupInfo src) {
this(src.getName(), src.servers, src.tables);
}
{code}
Just one concern: Is {{@NotNull}} an IntelliJ annotation? Findbugs and IntelliJ
support their own version of nullness annotation in terms of JSR 305.
> Improve RSGroupInfo constructors
>
>
> Key: HBASE-19702
> URL: https://issues.apache.org/jira/browse/HBASE-19702
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19702.master.000.patch
>
>
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfo.java|borderStyle=solid}
> RSGroupInfo(String name, SortedSet servers, SortedSet
> tables) {
> this.name = name;
> this.servers = servers == null? new TreeSet<>(): servers;
> this.servers.addAll(servers);
> this.tables = new TreeSet<>(tables);
> }
> {code}
> 2 improvements could be made:
> * When servers is not null, addAll(servers) tries to add all items in servers
> again. Seems not needed
> * new TreeSet<>(tables) has no null check on tables. The constructor of
> TreeSet does not do the null check either. It leads to NullPointerException
> if tables is null
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19702) Improve RSGroupInfo constructors
[
https://issues.apache.org/jira/browse/HBASE-19702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiang Li updated HBASE-19702:
-
Status: Patch Available (was: Open)
> Improve RSGroupInfo constructors
>
>
> Key: HBASE-19702
> URL: https://issues.apache.org/jira/browse/HBASE-19702
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19702.master.000.patch
>
>
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfo.java|borderStyle=solid}
> RSGroupInfo(String name, SortedSet servers, SortedSet
> tables) {
> this.name = name;
> this.servers = servers == null? new TreeSet<>(): servers;
> this.servers.addAll(servers);
> this.tables = new TreeSet<>(tables);
> }
> {code}
> 2 improvements could be made:
> * When servers is not null, addAll(servers) tries to add all items in servers
> again. Seems not needed
> * new TreeSet<>(tables) has no null check on tables. The constructor of
> TreeSet does not do the null check either. It leads to NullPointerException
> if tables is null
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19702) Improve RSGroupInfo constructors
[
https://issues.apache.org/jira/browse/HBASE-19702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiang Li updated HBASE-19702:
-
Attachment: HBASE-19702.master.000.patch
> Improve RSGroupInfo constructors
>
>
> Key: HBASE-19702
> URL: https://issues.apache.org/jira/browse/HBASE-19702
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19702.master.000.patch
>
>
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfo.java|borderStyle=solid}
> RSGroupInfo(String name, SortedSet servers, SortedSet
> tables) {
> this.name = name;
> this.servers = servers == null? new TreeSet<>(): servers;
> this.servers.addAll(servers);
> this.tables = new TreeSet<>(tables);
> }
> {code}
> 2 improvements could be made:
> * When servers is not null, addAll(servers) tries to add all items in servers
> again. Seems not needed
> * new TreeSet<>(tables) has no null check on tables. The constructor of
> TreeSet does not do the null check either. It leads to NullPointerException
> if tables is null
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-19702) Improve RSGroupInfo constructors
[
https://issues.apache.org/jira/browse/HBASE-19702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314547#comment-16314547
]
Xiang Li edited comment on HBASE-19702 at 1/6/18 1:02 PM:
--
[~chia7712], [~appy] Thanks for the comments!
Patch 000 is uploaded. One more change is made: I am not sure why in
{code}
public RSGroupInfo(RSGroupInfo src) {
this(src.getName(), src.servers, src.tables);
}
{code}
The fields of servers and tables are read from src directly, but name is read
by getXXX method. So I made them unified.
was (Author: water):
[~chia7712], [~appy] Thanks for the comments.
Patch 000 is uploaded. One more change is made: I am not sure why in
{code}
public RSGroupInfo(RSGroupInfo src) {
this(src.getName(), src.servers, src.tables);
}
{code}
The fields of servers and tables are read from src directly, but name is read
by getXXX method. So I made them unified.
> Improve RSGroupInfo constructors
>
>
> Key: HBASE-19702
> URL: https://issues.apache.org/jira/browse/HBASE-19702
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Fix For: 2.0.0-beta-2
>
>
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfo.java|borderStyle=solid}
> RSGroupInfo(String name, SortedSet servers, SortedSet
> tables) {
> this.name = name;
> this.servers = servers == null? new TreeSet<>(): servers;
> this.servers.addAll(servers);
> this.tables = new TreeSet<>(tables);
> }
> {code}
> 2 improvements could be made:
> * When servers is not null, addAll(servers) tries to add all items in servers
> again. Seems not needed
> * new TreeSet<>(tables) has no null check on tables. The constructor of
> TreeSet does not do the null check either. It leads to NullPointerException
> if tables is null
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19702) Improve RSGroupInfo constructors
[
https://issues.apache.org/jira/browse/HBASE-19702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314547#comment-16314547
]
Xiang Li commented on HBASE-19702:
--
[~chia7712] [~appy] Thanks for the comments.
Patch 000 is uploaded. One more change is made: I am not sure why in
{code}
public RSGroupInfo(RSGroupInfo src) {
this(src.getName(), src.servers, src.tables);
}
{code}
The fields of servers and tables are read from src directly, but name is read
by getXXX method. So I made them unified.
> Improve RSGroupInfo constructors
>
>
> Key: HBASE-19702
> URL: https://issues.apache.org/jira/browse/HBASE-19702
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Fix For: 2.0.0-beta-2
>
>
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfo.java|borderStyle=solid}
> RSGroupInfo(String name, SortedSet servers, SortedSet
> tables) {
> this.name = name;
> this.servers = servers == null? new TreeSet<>(): servers;
> this.servers.addAll(servers);
> this.tables = new TreeSet<>(tables);
> }
> {code}
> 2 improvements could be made:
> * When servers is not null, addAll(servers) tries to add all items in servers
> again. Seems not needed
> * new TreeSet<>(tables) has no null check on tables. The constructor of
> TreeSet does not do the null check either. It leads to NullPointerException
> if tables is null
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-19702) Improve RSGroupInfo constructors
[
https://issues.apache.org/jira/browse/HBASE-19702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314547#comment-16314547
]
Xiang Li edited comment on HBASE-19702 at 1/6/18 1:01 PM:
--
[~chia7712], [~appy] Thanks for the comments.
Patch 000 is uploaded. One more change is made: I am not sure why in
{code}
public RSGroupInfo(RSGroupInfo src) {
this(src.getName(), src.servers, src.tables);
}
{code}
The fields of servers and tables are read from src directly, but name is read
by getXXX method. So I made them unified.
was (Author: water):
[~chia7712] [~appy] Thanks for the comments.
Patch 000 is uploaded. One more change is made: I am not sure why in
{code}
public RSGroupInfo(RSGroupInfo src) {
this(src.getName(), src.servers, src.tables);
}
{code}
The fields of servers and tables are read from src directly, but name is read
by getXXX method. So I made them unified.
> Improve RSGroupInfo constructors
>
>
> Key: HBASE-19702
> URL: https://issues.apache.org/jira/browse/HBASE-19702
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Fix For: 2.0.0-beta-2
>
>
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfo.java|borderStyle=solid}
> RSGroupInfo(String name, SortedSet servers, SortedSet
> tables) {
> this.name = name;
> this.servers = servers == null? new TreeSet<>(): servers;
> this.servers.addAll(servers);
> this.tables = new TreeSet<>(tables);
> }
> {code}
> 2 improvements could be made:
> * When servers is not null, addAll(servers) tries to add all items in servers
> again. Seems not needed
> * new TreeSet<>(tables) has no null check on tables. The constructor of
> TreeSet does not do the null check either. It leads to NullPointerException
> if tables is null
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19702) Improve RSGroupInfo constructors
[
https://issues.apache.org/jira/browse/HBASE-19702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiang Li updated HBASE-19702:
-
Summary: Improve RSGroupInfo constructors (was: Improve RSGroupInfo
constructor)
> Improve RSGroupInfo constructors
>
>
> Key: HBASE-19702
> URL: https://issues.apache.org/jira/browse/HBASE-19702
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Fix For: 2.0.0-beta-2
>
>
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfo.java|borderStyle=solid}
> RSGroupInfo(String name, SortedSet servers, SortedSet
> tables) {
> this.name = name;
> this.servers = servers == null? new TreeSet<>(): servers;
> this.servers.addAll(servers);
> this.tables = new TreeSet<>(tables);
> }
> {code}
> 2 improvements could be made:
> * When servers is not null, addAll(servers) tries to add all items in servers
> again. Seems not needed
> * new TreeSet<>(tables) has no null check on tables. The constructor of
> TreeSet does not do the null check either. It leads to NullPointerException
> if tables is null
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19358) Improve the stability of splitting log when do fail over
[ https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-19358: - Attachment: HBASE-19358-branch-2-v3.patch > Improve the stability of splitting log when do fail over > > > Key: HBASE-19358 > URL: https://issues.apache.org/jira/browse/HBASE-19358 > Project: HBase > Issue Type: Improvement > Components: MTTR >Affects Versions: 0.98.24 >Reporter: Jingyun Tian >Assignee: Jingyun Tian > Fix For: 1.4.1, 1.5.0, 2.0.0-beta-2 > > Attachments: HBASE-18619-branch-2-v2.patch, > HBASE-19358-branch-1-v2.patch, HBASE-19358-branch-1-v3.patch, > HBASE-19358-branch-1.patch, HBASE-19358-branch-2-v3.patch, > HBASE-19358-v1.patch, HBASE-19358-v4.patch, HBASE-19358-v5.patch, > HBASE-19358-v6.patch, HBASE-19358-v7.patch, HBASE-19358-v8.patch, > HBASE-19358.patch > > > The way we splitting log now is like the following figure: > !https://issues.apache.org/jira/secure/attachment/12904506/split-logic-old.jpg! > The problem is the OutputSink will write the recovered edits during splitting > log, which means it will create one WriterAndPath for each region and retain > it until the end. If the cluster is small and the number of regions per rs is > large, it will create too many HDFS streams at the same time. Then it is > prone to failure since each datanode need to handle too many streams. > Thus I come up with a new way to split log. > !https://issues.apache.org/jira/secure/attachment/12904507/split-logic-new.jpg! > We try to cache all the recovered edits, but if it exceeds the MaxHeapUsage, > we will pick the largest EntryBuffer and write it to a file (close the writer > after finish). Then after we read all entries into memory, we will start a > writeAndCloseThreadPool, it starts a certain number of threads to write all > buffers to files. Thus it will not create HDFS streams more than > *_hbase.regionserver.hlog.splitlog.writer.threads_* we set. > The biggest benefit is we can control the number of streams we create during > splitting log, > it will not exceeds *_hbase.regionserver.wal.max.splitters * > hbase.regionserver.hlog.splitlog.writer.threads_*, but before it is > *_hbase.regionserver.wal.max.splitters * the number of region the hlog > contains_*. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19358) Improve the stability of splitting log when do fail over
[ https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-19358: - Attachment: (was: HBASE-19358-branch-2-v3.patch) > Improve the stability of splitting log when do fail over > > > Key: HBASE-19358 > URL: https://issues.apache.org/jira/browse/HBASE-19358 > Project: HBase > Issue Type: Improvement > Components: MTTR >Affects Versions: 0.98.24 >Reporter: Jingyun Tian >Assignee: Jingyun Tian > Fix For: 1.4.1, 1.5.0, 2.0.0-beta-2 > > Attachments: HBASE-18619-branch-2-v2.patch, > HBASE-19358-branch-1-v2.patch, HBASE-19358-branch-1-v3.patch, > HBASE-19358-branch-1.patch, HBASE-19358-branch-2-v3.patch, > HBASE-19358-v1.patch, HBASE-19358-v4.patch, HBASE-19358-v5.patch, > HBASE-19358-v6.patch, HBASE-19358-v7.patch, HBASE-19358-v8.patch, > HBASE-19358.patch > > > The way we splitting log now is like the following figure: > !https://issues.apache.org/jira/secure/attachment/12904506/split-logic-old.jpg! > The problem is the OutputSink will write the recovered edits during splitting > log, which means it will create one WriterAndPath for each region and retain > it until the end. If the cluster is small and the number of regions per rs is > large, it will create too many HDFS streams at the same time. Then it is > prone to failure since each datanode need to handle too many streams. > Thus I come up with a new way to split log. > !https://issues.apache.org/jira/secure/attachment/12904507/split-logic-new.jpg! > We try to cache all the recovered edits, but if it exceeds the MaxHeapUsage, > we will pick the largest EntryBuffer and write it to a file (close the writer > after finish). Then after we read all entries into memory, we will start a > writeAndCloseThreadPool, it starts a certain number of threads to write all > buffers to files. Thus it will not create HDFS streams more than > *_hbase.regionserver.hlog.splitlog.writer.threads_* we set. > The biggest benefit is we can control the number of streams we create during > splitting log, > it will not exceeds *_hbase.regionserver.wal.max.splitters * > hbase.regionserver.hlog.splitlog.writer.threads_*, but before it is > *_hbase.regionserver.wal.max.splitters * the number of region the hlog > contains_*. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19706) Cells are always eclipsed by Deleted cells even if in time range scan
[ https://issues.apache.org/jira/browse/HBASE-19706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Singhal updated HBASE-19706: -- Resolution: Not A Problem Status: Resolved (was: Patch Available) > Cells are always eclipsed by Deleted cells even if in time range scan > - > > Key: HBASE-19706 > URL: https://issues.apache.org/jira/browse/HBASE-19706 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0-beta-1 >Reporter: Ankit Singhal >Assignee: Ankit Singhal >Priority: Critical > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19706.patch, HBASE-19706_v1.patch, > HBASE-19706_v2.patch > > > Deleted cells are always hiding the other cells even if the scan ran with > time range having no delete marker. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-19706) Cells are always eclipsed by Deleted cells even if in time range scan
[
https://issues.apache.org/jira/browse/HBASE-19706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314439#comment-16314439
]
Ankit Singhal edited comment on HBASE-19706 at 1/6/18 12:06 PM:
I just noticed that we hide cells with deleted cells purposely in case of
non-raw scan and when KEEP_DELETED_CELLS is set to false. In order to have a
consistent view before and after compaction.
{code}
if (PrivateCellUtil.isDelete(typeByte)) {
boolean includeDeleteMarker = seePastDeleteMarkers ?
tr.withinTimeRange(timestamp)
: tr.withinOrAfterTimeRange(timestamp);
if (includeDeleteMarker) {
this.deletes.add(cell);
}
return MatchCode.SKIP;
}
{code}
[~anoopsamjohn], [~ram_krish], [~te...@apache.org] I'm sorry, my bad. it is
like this from long a time in HBase, we just workaround this case in
Phoenix(with PHOENIX-4277). Resolving this ticket as it is working as designed.
was (Author: an...@apache.org):
I just noticed that we hide cells with deleted cells purposely in case of
non-raw scan and when KEEP_DELETED_CELLS is set to false. Probably to have a
consistent view before and after compaction.
{code}
if (PrivateCellUtil.isDelete(typeByte)) {
boolean includeDeleteMarker = seePastDeleteMarkers ?
tr.withinTimeRange(timestamp)
: tr.withinOrAfterTimeRange(timestamp);
if (includeDeleteMarker) {
this.deletes.add(cell);
}
return MatchCode.SKIP;
}
{code}
[~anoopsamjohn], [~ram_krish], [~te...@apache.org] if this regression is
intentional, should we close this JIRA and handle the things at Phoenix side
accordingly?
> Cells are always eclipsed by Deleted cells even if in time range scan
> -
>
> Key: HBASE-19706
> URL: https://issues.apache.org/jira/browse/HBASE-19706
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0-beta-1
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Critical
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19706.patch, HBASE-19706_v1.patch,
> HBASE-19706_v2.patch
>
>
> Deleted cells are always hiding the other cells even if the scan ran with
> time range having no delete marker.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19397) Design procedures for ReplicationManager to notify peer change event from master
[
https://issues.apache.org/jira/browse/HBASE-19397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314507#comment-16314507
]
Hadoop QA commented on HBASE-19397:
---
| (x) *{color:red}-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:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 33 new or modified test
files. {color} |
|| || || || {color:brown} branch-2 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
46s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
21s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
32s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
8s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
21s{color} | {color:green} branch-2 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
12s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s{color} | {color:green} The patch hbase-protocol-shaded passed checkstyle
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
26s{color} | {color:green} The patch hbase-common passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
36s{color} | {color:green} hbase-client: The patch generated 0 new + 557
unchanged - 1 fixed = 557 total (was 558) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
12s{color} | {color:green} The patch hbase-zookeeper passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s{color} | {color:green} hbase-replication: The patch generated 0 new + 22
unchanged - 36 fixed = 22 total (was 58) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
14s{color} | {color:green} hbase-procedure: The patch generated 0 new + 4
unchanged - 2 fixed = 4 total (was 6) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
18s{color} | {color:red} hbase-server: The patch generated 6 new + 860
unchanged - 91 fixed = 866 total (was 951) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
18s{color} | {color:green} hbase-mapreduce: The patch generated 0 new + 10
unchanged - 2 fixed = 10 total (was 12) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s{color} | {color:green} The patch hbase-shell passed checkstyle {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
4s{color} | {color:red} The patch generated 10 new + 65 unchanged - 1 fixed =
75 total (was 66) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
2s{color} | {color:red} The patch generated 4 new + 79 unchanged - 0 fixed = 83
total (was 79) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
1s{color} | {color:green} The patch has no whitespace issues. {color} |
|
[jira] [Commented] (HBASE-19712) Fix TestSnapshotQuotaObserverChore#testSnapshotSize
[
https://issues.apache.org/jira/browse/HBASE-19712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314501#comment-16314501
]
Hadoop QA commented on HBASE-19712:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
9s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
37s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
27s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
33s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
19m 12s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
27s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 96m 38s{color}
| {color:red} hbase-server in the patch failed. {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}134m 33s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.security.token.TestGenerateDelegationToken |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19712 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12904930/HBASE-19712.v1.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux c4f89a90c731 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 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 / 54928ce3ea |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/10914/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/10914/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10914/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> Fix
[jira] [Commented] (HBASE-19397) Design procedures for ReplicationManager to notify peer change event from master
[
https://issues.apache.org/jira/browse/HBASE-19397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314500#comment-16314500
]
Hadoop QA commented on HBASE-19397:
---
| (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:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 33 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
12s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
37s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
13s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
12s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s{color} | {color:green} The patch hbase-protocol-shaded passed checkstyle
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
23s{color} | {color:green} The patch hbase-common passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
35s{color} | {color:green} hbase-client: The patch generated 0 new + 556
unchanged - 1 fixed = 556 total (was 557) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s{color} | {color:green} The patch hbase-zookeeper passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s{color} | {color:green} hbase-replication: The patch generated 0 new + 22
unchanged - 36 fixed = 22 total (was 58) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s{color} | {color:green} hbase-procedure: The patch generated 0 new + 4
unchanged - 2 fixed = 4 total (was 6) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
16s{color} | {color:red} hbase-server: The patch generated 6 new + 860
unchanged - 91 fixed = 866 total (was 951) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
16s{color} | {color:green} hbase-mapreduce: The patch generated 0 new + 10
unchanged - 2 fixed = 10 total (was 12) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s{color} | {color:green} The patch hbase-shell passed checkstyle {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
4s{color} | {color:red} The patch generated 10 new + 65 unchanged - 1 fixed =
75 total (was 66) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
3s{color} | {color:red} The patch generated 4 new + 79 unchanged - 0 fixed = 83
total (was 79) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
|
[jira] [Updated] (HBASE-19673) Backport " Periodically ensure records are not buffered too long by BufferedMutator" to branch-1
[ https://issues.apache.org/jira/browse/HBASE-19673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19673: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Thanks for the patch. [~nielsbasjes] > Backport " Periodically ensure records are not buffered too long by > BufferedMutator" to branch-1 > > > Key: HBASE-19673 > URL: https://issues.apache.org/jira/browse/HBASE-19673 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Niels Basjes >Assignee: Niels Basjes > Fix For: 1.5.0 > > Attachments: HBASE-19673.20171230-130631.branch-1.patch, > HBASE-19673.20171230-131955.branch-1.patch, > HBASE-19673.20171231-112539.branch-1.patch, > HBASE-19673.20180102-082937.branch-1.patch, > HBASE-19673.20180102-155006.branch-1.patch, > HBASE-19673.20180103-084857.branch-1.patch, > HBASE-19673.branch-1.20180103-170905.patch, > HBASE-19673.branch-1.20180105-092230.patch > > > In HBASE-19486 the feature was built to periodically flush the > BufferedMutator. > Because backwards compatibility is important in the 1.x branch some > refactoring is needed to make this work. > As requested by [~chia7712] this separate issue was created -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19712) Fix TestSnapshotQuotaObserverChore#testSnapshotSize
[ https://issues.apache.org/jira/browse/HBASE-19712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19712: --- Attachment: HBASE-19712.v1.patch v1 is based on [~elserj]'s suggestion. > Fix TestSnapshotQuotaObserverChore#testSnapshotSize > --- > > Key: HBASE-19712 > URL: https://issues.apache.org/jira/browse/HBASE-19712 > Project: HBase > Issue Type: Bug > Components: test >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19712.v0.patch, HBASE-19712.v1.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19673) Backport " Periodically ensure records are not buffered too long by BufferedMutator" to branch-1
[ https://issues.apache.org/jira/browse/HBASE-19673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19673: --- Fix Version/s: 1.5.0 > Backport " Periodically ensure records are not buffered too long by > BufferedMutator" to branch-1 > > > Key: HBASE-19673 > URL: https://issues.apache.org/jira/browse/HBASE-19673 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Niels Basjes >Assignee: Niels Basjes > Fix For: 1.5.0 > > Attachments: HBASE-19673.20171230-130631.branch-1.patch, > HBASE-19673.20171230-131955.branch-1.patch, > HBASE-19673.20171231-112539.branch-1.patch, > HBASE-19673.20180102-082937.branch-1.patch, > HBASE-19673.20180102-155006.branch-1.patch, > HBASE-19673.20180103-084857.branch-1.patch, > HBASE-19673.branch-1.20180103-170905.patch, > HBASE-19673.branch-1.20180105-092230.patch > > > In HBASE-19486 the feature was built to periodically flush the > BufferedMutator. > Because backwards compatibility is important in the 1.x branch some > refactoring is needed to make this work. > As requested by [~chia7712] this separate issue was created -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19706) Cells are always eclipsed by Deleted cells even if in time range scan
[
https://issues.apache.org/jira/browse/HBASE-19706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16314439#comment-16314439
]
Ankit Singhal commented on HBASE-19706:
---
I just noticed that we hide cells with deleted cells purposely in case of
non-raw scan and when KEEP_DELETED_CELLS is set to false. Probably to have a
consistent view before and after compaction.
{code}
if (PrivateCellUtil.isDelete(typeByte)) {
boolean includeDeleteMarker = seePastDeleteMarkers ?
tr.withinTimeRange(timestamp)
: tr.withinOrAfterTimeRange(timestamp);
if (includeDeleteMarker) {
this.deletes.add(cell);
}
return MatchCode.SKIP;
}
{code}
[~anoopsamjohn], [~ram_krish], [~te...@apache.org] if this regression is
intentional, should we close this JIRA and handle the things at Phoenix side
accordingly?
> Cells are always eclipsed by Deleted cells even if in time range scan
> -
>
> Key: HBASE-19706
> URL: https://issues.apache.org/jira/browse/HBASE-19706
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0-beta-1
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Critical
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19706.patch, HBASE-19706_v1.patch,
> HBASE-19706_v2.patch
>
>
> Deleted cells are always hiding the other cells even if the scan ran with
> time range having no delete marker.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
