[jira] [Commented] (HBASE-19054) Switch precommit docker image to one based on maven images
[
https://issues.apache.org/jira/browse/HBASE-19054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214200#comment-16214200
]
Sean Busbey commented on HBASE-19054:
-
this showed up a few times. I'm pretty sure that means we skip getting logs,
etc.
{code}
04:45:05.831 executable '' for 'rsync' does not exist.
04:45:05.831 WARNING: Cannot use the archive function
{code}
> Switch precommit docker image to one based on maven images
> --
>
> Key: HBASE-19054
> URL: https://issues.apache.org/jira/browse/HBASE-19054
> Project: HBase
> Issue Type: Bug
> Components: build, community
>Reporter: Mike Drob
>Assignee: Mike Drob
> Attachments: HBASE-19054.patch, HBASE-19054.v2.patch
>
>
> In HBASE-19042 we discuss moving to a maven-based image for docker instead of
> going through gymnastics ourselves. We got a short term fix in there, but
> let's do the bulk of the cleanup here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18247) Hbck to fix the case that replica region shows as key in the meta table
[
https://issues.apache.org/jira/browse/HBASE-18247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-18247:
Resolution: Fixed
Release Note: The hbck tool can no correct the meta table should it get an
entry for a read replica region.
Status: Resolved (was: Patch Available)
Filed HBASE-19063 for the master/branch-2 work. Closing this out since it is in
version(s) nearing release.
> Hbck to fix the case that replica region shows as key in the meta table
> ---
>
> Key: HBASE-18247
> URL: https://issues.apache.org/jira/browse/HBASE-18247
> Project: HBase
> Issue Type: Bug
> Components: hbck, Operability
>Affects Versions: 2.0.0-alpha-1
>Reporter: huaxiang sun
>Assignee: huaxiang sun
>Priority: Minor
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7
>
> Attachments: HBASE-18247-branch-1.2-v001.patch
>
>
> Recently, we run into one case with read replica, the replica region shows up
> as key in meta table (it is not supposed to happen, we are still working on
> why it showed up in the meta table).
> However, hbck always reported the error about the primary region. Please see
> the error attached.
> {code}
> The entry in meta table
> test,92b0201b,1492546349354_0001.c3e6f235fe7caef75f8b0fb92a012da3.
> column=info:regioninfo, timestamp=1494958820573, value={ENCODED =>
> c3e6f235fe7caef75f8b0fb92a012da3, NAME =>
> 'test,92b0201b,1492546349354_0001.c3e6f235fe7caef75f8b0fb92a012da3.',
> STARTKEY => '92b0201b', ENDKEY => '92f1a952', REPLICA_ID => 1}
> ERROR: Region { meta =>
> test,92b0201b,1492546349354.d2c637715f31a072f174e70d407fb458., hdfs => null,
> deployed => , replicaId => 0 } found in META, but not in HDFS or deployed on
> any region server.
> {code}
> Traced the code, in the following line, it does not consider the case that
> replicaId in regionInfo could be non-default.
> https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/MetaTableAccessor.java#L985
> If it is changed to get replicaId from regionInfo, then hbck should be able
> to fix this by "-fixMeta".
> {code}
> diff --git
> a/hbase-client/src/main/java/org/apache/hadoop/hbase/MetaTableAccessor.java
> b/hbase-client/src/main/java/org/apache/hadoop/hbase/MetaTableAccessor.java
> index 9eb5111..1649e53 100644
> ---
> a/hbase-client/src/main/java/org/apache/hadoop/hbase/MetaTableAccessor.java
> +++
> b/hbase-client/src/main/java/org/apache/hadoop/hbase/MetaTableAccessor.java
> @@ -982,7 +982,7 @@ public class MetaTableAccessor {
> List locations = new ArrayList<>(1);
> NavigableMap> familyMap =
> r.getNoVersionMap();
>
> -locations.add(getRegionLocation(r, regionInfo, 0));
> +locations.add(getRegionLocation(r, regionInfo,
> regionInfo.getReplicaId()));
>
> NavigableMap infoMap = familyMap.get(getCatalogFamily());
> if (infoMap == null) return new RegionLocations(locations);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19063) Ensure branch-2 and master have needed equivalent to HBASE-18247 'Hbck to fix the case that replica region shows as key in the meta table'
Sean Busbey created HBASE-19063: --- Summary: Ensure branch-2 and master have needed equivalent to HBASE-18247 'Hbck to fix the case that replica region shows as key in the meta table' Key: HBASE-19063 URL: https://issues.apache.org/jira/browse/HBASE-19063 Project: HBase Issue Type: Bug Components: hbck, Operability Affects Versions: 2.0.0-alpha-3, 3.0.0 Reporter: Sean Busbey Priority: Minor Fix For: 2.0.0, 3.0.0 HBASE-18247's addition to hbck is only in branches-1* (1.2+). It did not get into master/branch-2 because of a merge failure. Before 2.0 goes out we should make sure hbck has whatever it needs to deal with the same issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18993) Backport patches in HBASE-18410 to branch-1.x branches.
[
https://issues.apache.org/jira/browse/HBASE-18993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214195#comment-16214195
]
Hadoop QA commented on HBASE-18993:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
24s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
4s{color} | {color:green} branch-1.4 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
48s{color} | {color:green} branch-1.4 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
52s{color} | {color:green} branch-1.4 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
41s{color} | {color:green} branch-1.4 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
45s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
43s{color} | {color:green} branch-1.4 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
57s{color} | {color:green} branch-1.4 passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
10s{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 33s{color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3.
{color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
7s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}1463m 39s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}1514m 29s{color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:89abc29 |
| JIRA Issue | HBASE-18993 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893392/HBASE-18993-branch-1.4.v1.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 3f6e31d3707f 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | branch-1.4 / 89abc29
[jira] [Updated] (HBASE-17890) FuzzyRowFilter fail if unaligned support is false
[
https://issues.apache.org/jira/browse/HBASE-17890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-17890:
Status: In Progress (was: Patch Available)
moving out of patch available since patch needs a rebase.
> FuzzyRowFilter fail if unaligned support is false
> -
>
> Key: HBASE-17890
> URL: https://issues.apache.org/jira/browse/HBASE-17890
> Project: HBase
> Issue Type: Sub-task
> Components: util
>Affects Versions: 1.2.5, 2.0.0
>Reporter: Jerry He
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.2.7
>
> Attachments: HBASE-17890.v0.branch-1.patch, HBASE-17890.v0.patch,
> HBASE-17890.v1.branch-1.patch, HBASE-17890.v1.patch, HBASE-17890.v2.patch,
> HBASE-17890.v3.patch, HBASE-17890.v3.patch, HBASE-17890.v3.patch,
> HBASE-17890.v3.patch, HBASE-17890.v3.patch
>
>
> When unaligned support is false, FuzzyRow tests fail:
> {noformat}
> Failed tests:
> TestFuzzyRowAndColumnRangeFilter.Test:134->runTest:157->runScanner:186
> expected:<10> but was:<0>
> TestFuzzyRowFilter.testSatisfiesForward:81 expected: but was:
> TestFuzzyRowFilter.testSatisfiesReverse:121 expected: but
> was:
> TestFuzzyRowFilterEndToEnd.testEndToEnd:247->runTest1:278->runScanner:343
> expected:<6250> but was:<0>
> TestFuzzyRowFilterEndToEnd.testFilterList:385->runTest:417->runScanner:445
> expected:<5> but was:<0>
> TestFuzzyRowFilterEndToEnd.testHBASE14782:204 expected:<6> but was:<0>
> {noformat}
> This can be reproduced in the case described in HBASE-17869. Or on a platform
> really without unaligned support.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18182) Setting HBASE_REGIONSERVER_OPTS with UseG1GC will cause regionserver start error
[
https://issues.apache.org/jira/browse/HBASE-18182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214193#comment-16214193
]
Hadoop QA commented on HBASE-18182:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
20s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
4s{color} | {color:blue} Shelldocs was not available. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
4s{color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
10s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 0m 43s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:cb5c477 |
| JIRA Issue | HBASE-18182 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12871795/HBASE-18182.0.patch |
| Optional Tests | asflicense shellcheck shelldocs |
| uname | Linux 15ec1749a36f 3.13.0-116-generic #163-Ubuntu SMP Fri Mar 31
14:13:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 2ee8690 |
| shellcheck | v0.4.6 |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9317/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Setting HBASE_REGIONSERVER_OPTS with UseG1GC will cause regionserver start
> error
>
>
> Key: HBASE-18182
> URL: https://issues.apache.org/jira/browse/HBASE-18182
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0, 1.1.6, 1.3.1, 1.2.6
>Reporter: Fangyuan Deng
>Assignee: Fangyuan Deng
> Fix For: 2.1.0, 1.3.2, 1.2.7
>
> Attachments: HBASE-18182.0.patch
>
>
> when we set in hbase-env.sh to use G1GC
> HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -XX:+UseG1GC -Xms96g
> -Xmx96g -XX:MaxGCPauseMillis=100"
> then run ./hbase-daemon.sh start regionserver
> Conflicting collector combinations in option list; please refer to the
> release notes for the combinations allowed
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> because the HBASE_OPTS default use CMS and is conflicted with
> HBASE_REGIONSERVER_OPTS
> so I add a patch to modify bin/hbase like this
> elif [ "$COMMAND" = "regionserver" ] ; then
> CLASS='org.apache.hadoop.hbase.regionserver.HRegionServer'
> if [ "$1" != "stop" ] ; then
> HBASE_OPTS="$HBASE_OPTS $HBASE_REGIONSERVER_OPTS"
> if [[ $HBASE_REGIONSERVER_OPTS == *UseG1GC* ]] ; then
> HBASE_OPTS=${HBASE_OPTS/'-XX:+UseConcMarkSweepGC'/''}
> fi
> fi
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18483) The RpcRetryingCaller#translateException doesn't handle RemoteException
[
https://issues.apache.org/jira/browse/HBASE-18483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-18483:
Status: In Progress (was: Patch Available)
moved out of patch available. Still working on this [~takumi]?
> The RpcRetryingCaller#translateException doesn't handle RemoteException
> ---
>
> Key: HBASE-18483
> URL: https://issues.apache.org/jira/browse/HBASE-18483
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.2.6, 1.3.1
>Reporter: Chia-Ping Tsai
>Assignee: Hao Chan
>Priority: Minor
> Labels: beginner
> Fix For: 1.4.0, 1.3.2, 1.5.0, 1.2.7
>
> Attachments: HBASE-18483.branch-1.3.v0.patch
>
>
> {code}
> if (t instanceof ServiceException) {
> ServiceException se = (ServiceException)t;
> Throwable cause = se.getCause();
> if (cause != null) {
> if (cause instanceof DoNotRetryIOException) {
> throw (DoNotRetryIOException)cause;
> } else if (cause instanceof NeedUnmanagedConnectionException) {
> throw new DoNotRetryIOException(cause);
> }
> }
> // Don't let ServiceException out; its rpc specific.
> t = cause;
> // t could be a RemoteException so go aaround again.
> translateException(t); // here
> } else if (t instanceof DoNotRetryIOException) {
> throw (DoNotRetryIOException)t;
> } else if (t instanceof NeedUnmanagedConnectionException) {
> throw new DoNotRetryIOException(t);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18182) Setting HBASE_REGIONSERVER_OPTS with UseG1GC will cause regionserver start error
[
https://issues.apache.org/jira/browse/HBASE-18182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214191#comment-16214191
]
Sean Busbey commented on HBASE-18182:
-
Thanks for the contribution!
The default HBASE_OPTS gets set in {{hbase-env.sh}}, which is a part of
{{HBASE_CONF_DIR}}. Whats the trade off on doing this kind of post-hoc removal
vs just pointing out the need to remove it for folks who want to use g1gc?
Presuming we keep this kind of logic, we should do the same check for other
roles I think? Like there's no reason to make using G1GC hard for e.g. the
Thrift servers.
> Setting HBASE_REGIONSERVER_OPTS with UseG1GC will cause regionserver start
> error
>
>
> Key: HBASE-18182
> URL: https://issues.apache.org/jira/browse/HBASE-18182
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.0.0, 1.1.6, 1.3.1, 1.2.6
>Reporter: Fangyuan Deng
>Assignee: Fangyuan Deng
> Fix For: 2.1.0, 1.3.2, 1.2.7
>
> Attachments: HBASE-18182.0.patch
>
>
> when we set in hbase-env.sh to use G1GC
> HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -XX:+UseG1GC -Xms96g
> -Xmx96g -XX:MaxGCPauseMillis=100"
> then run ./hbase-daemon.sh start regionserver
> Conflicting collector combinations in option list; please refer to the
> release notes for the combinations allowed
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> because the HBASE_OPTS default use CMS and is conflicted with
> HBASE_REGIONSERVER_OPTS
> so I add a patch to modify bin/hbase like this
> elif [ "$COMMAND" = "regionserver" ] ; then
> CLASS='org.apache.hadoop.hbase.regionserver.HRegionServer'
> if [ "$1" != "stop" ] ; then
> HBASE_OPTS="$HBASE_OPTS $HBASE_REGIONSERVER_OPTS"
> if [[ $HBASE_REGIONSERVER_OPTS == *UseG1GC* ]] ; then
> HBASE_OPTS=${HBASE_OPTS/'-XX:+UseConcMarkSweepGC'/''}
> fi
> fi
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19030) nightly runs should attempt to log test results after archiving
[ https://issues.apache.org/jira/browse/HBASE-19030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214187#comment-16214187 ] Sean Busbey commented on HBASE-19030: - bump. can I get a review here? small change. > nightly runs should attempt to log test results after archiving > --- > > Key: HBASE-19030 > URL: https://issues.apache.org/jira/browse/HBASE-19030 > Project: HBase > Issue Type: Bug > Components: test >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Attachments: HBASE-19030.0.patch > > > right now on the nightly tests the first post-action we do is log junit > results. due to current limitations of Jenkins DSL, if this step fails none > of the other post actions will happen. > Since we might not make junit test results, e.g. in the case of a timeout of > yetus itself, we should log the junit results after we've saved whatever we > can of yetus output. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17890) FuzzyRowFilter fail if unaligned support is false
[
https://issues.apache.org/jira/browse/HBASE-17890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214190#comment-16214190
]
Hadoop QA commented on HBASE-17890:
---
| (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 5s{color}
| {color:red} HBASE-17890 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-17890 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12863726/HBASE-17890.v3.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9315/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> FuzzyRowFilter fail if unaligned support is false
> -
>
> Key: HBASE-17890
> URL: https://issues.apache.org/jira/browse/HBASE-17890
> Project: HBase
> Issue Type: Sub-task
> Components: util
>Affects Versions: 2.0.0, 1.2.5
>Reporter: Jerry He
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.2.7
>
> Attachments: HBASE-17890.v0.branch-1.patch, HBASE-17890.v0.patch,
> HBASE-17890.v1.branch-1.patch, HBASE-17890.v1.patch, HBASE-17890.v2.patch,
> HBASE-17890.v3.patch, HBASE-17890.v3.patch, HBASE-17890.v3.patch,
> HBASE-17890.v3.patch, HBASE-17890.v3.patch
>
>
> When unaligned support is false, FuzzyRow tests fail:
> {noformat}
> Failed tests:
> TestFuzzyRowAndColumnRangeFilter.Test:134->runTest:157->runScanner:186
> expected:<10> but was:<0>
> TestFuzzyRowFilter.testSatisfiesForward:81 expected: but was:
> TestFuzzyRowFilter.testSatisfiesReverse:121 expected: but
> was:
> TestFuzzyRowFilterEndToEnd.testEndToEnd:247->runTest1:278->runScanner:343
> expected:<6250> but was:<0>
> TestFuzzyRowFilterEndToEnd.testFilterList:385->runTest:417->runScanner:445
> expected:<5> but was:<0>
> TestFuzzyRowFilterEndToEnd.testHBASE14782:204 expected:<6> but was:<0>
> {noformat}
> This can be reproduced in the case described in HBASE-17869. Or on a platform
> really without unaligned support.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-17890) FuzzyRowFilter fail if unaligned support is false
[
https://issues.apache.org/jira/browse/HBASE-17890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214189#comment-16214189
]
Hadoop QA commented on HBASE-17890:
---
| (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 5s{color}
| {color:red} HBASE-17890 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-17890 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12863726/HBASE-17890.v3.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9314/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> FuzzyRowFilter fail if unaligned support is false
> -
>
> Key: HBASE-17890
> URL: https://issues.apache.org/jira/browse/HBASE-17890
> Project: HBase
> Issue Type: Sub-task
> Components: util
>Affects Versions: 2.0.0, 1.2.5
>Reporter: Jerry He
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.2.7
>
> Attachments: HBASE-17890.v0.branch-1.patch, HBASE-17890.v0.patch,
> HBASE-17890.v1.branch-1.patch, HBASE-17890.v1.patch, HBASE-17890.v2.patch,
> HBASE-17890.v3.patch, HBASE-17890.v3.patch, HBASE-17890.v3.patch,
> HBASE-17890.v3.patch, HBASE-17890.v3.patch
>
>
> When unaligned support is false, FuzzyRow tests fail:
> {noformat}
> Failed tests:
> TestFuzzyRowAndColumnRangeFilter.Test:134->runTest:157->runScanner:186
> expected:<10> but was:<0>
> TestFuzzyRowFilter.testSatisfiesForward:81 expected: but was:
> TestFuzzyRowFilter.testSatisfiesReverse:121 expected: but
> was:
> TestFuzzyRowFilterEndToEnd.testEndToEnd:247->runTest1:278->runScanner:343
> expected:<6250> but was:<0>
> TestFuzzyRowFilterEndToEnd.testFilterList:385->runTest:417->runScanner:445
> expected:<5> but was:<0>
> TestFuzzyRowFilterEndToEnd.testHBASE14782:204 expected:<6> but was:<0>
> {noformat}
> This can be reproduced in the case described in HBASE-17869. Or on a platform
> really without unaligned support.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18645) Loads of tests timing out....
[ https://issues.apache.org/jira/browse/HBASE-18645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18645: Status: In Progress (was: Patch Available) moving out of patch available since the attached revert was applied some time ago. > Loads of tests timing out > - > > Key: HBASE-18645 > URL: https://issues.apache.org/jira/browse/HBASE-18645 > Project: HBase > Issue Type: Bug >Reporter: stack >Priority: Critical > Attachments: HBASE-18645.master.001.patch, > HBASE-18645.master.001.patch > > > Whats up? Why are tests mostly timing out? When did it start? I can't seem to > make it happen locally so tough doing a bisect. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19029) Align RPC timout methods in Table and AsyncTableBase
[
https://issues.apache.org/jira/browse/HBASE-19029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214183#comment-16214183
]
Peter Somogyi commented on HBASE-19029:
---
Can someone take a look? Thanks
> Align RPC timout methods in Table and AsyncTableBase
>
>
> Key: HBASE-19029
> URL: https://issues.apache.org/jira/browse/HBASE-19029
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client
>Affects Versions: 2.0.0-alpha-3
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19029.master.001.patch,
> HBASE-19029.master.002.patch, HBASE-19029.master.002.patch,
> HBASE-19029.master.003.patch, HBASE-19029.master.003.patch,
> HBASE-19029.master.003.patch
>
>
> Table and AsyncTableBase have similar RPC timeout methods but the async
> version supports TimeUtils to be passed.
> To align these 2 interfaces lets depricate the existing methods in Table and
> add the ones that are currently in AsyncTableBase.
> These methods are the following:
> * long getRpcTimeout(TimeUnit unit)
> * long getReadRpcTimeout(TimeUnit unit)
> * long getWriteRpcTimeout(TimeUnit unit)
> * long getOperationTimeout(TimeUnit unit)
> We do not have {{long getScanTimeout(TimeUnit unit)}} since scan is handled
> differently.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[
https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214184#comment-16214184
]
stack commented on HBASE-18846:
---
.005 Addresses [~mdrob] review and fixes tests.
> Accommodate the hbase-indexer/lily/SEP consumer deploy-type
> ---
>
> Key: HBASE-18846
> URL: https://issues.apache.org/jira/browse/HBASE-18846
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18846.master.001.patch,
> HBASE-18846.master.002.patch, HBASE-18846.master.003.patch,
> HBASE-18846.master.004.patch, HBASE-18846.master.005.patch,
> IndexerConnection.java, hbase-site.xml, javadoc.txt
>
>
> This is a follow-on from HBASE-10504, Define a Replication Interface. There
> we defined a new, flexible replication endpoint for others to implement but
> it did little to help the case of the lily hbase-indexer. This issue takes up
> the case of the hbase-indexer.
> The hbase-indexer poses to hbase as a 'fake' peer cluster (For why
> hbase-indexer is implemented so, the advantage to having the indexing done in
> a separate process set that can be independently scaled, can participate in
> the same security realm, etc., see discussion in HBASE-10504). The
> hbase-indexer will start up a cut-down "RegionServer" processes that are just
> an instance of hbase RpcServer hosting an AdminProtos Service. They make
> themselves 'appear' to the Replication Source by hoisting up an ephemeral
> znode 'registering' as a RegionServer. The source cluster then streams
> WALEdits to the Admin Protos method:
> {code}
> public ReplicateWALEntryResponse replicateWALEntry(final RpcController
> controller,
> final ReplicateWALEntryRequest request) throws ServiceException {
> {code}
> The hbase-indexer relies on other hbase internals like Server so it can get a
> ZooKeeperWatcher instance and know the 'name' to use for this cut-down server.
> Thoughts on how to proceed include:
>
> * Better formalize its current digestion of hbase internals; make it so
> rpcserver is allowed to be used by others, etc. This would be hard to do
> given they use basics like Server, Protobuf serdes for WAL types, and
> AdminProtos Service. Any change in this wide API breaks (again)
> hbase-indexer. We have made a 'channel' for Coprocessor Endpoints so they
> continue to work though they use 'internal' types. They can use protos in
> hbase-protocol. hbase-protocol protos are in a limbo currently where they are
> sort-of 'public'; a TODO. Perhaps the hbase-indexer could do similar relying
> on the hbase-protocol (pb2.5) content and we could do something to reveal
> rpcserver and zk for hbase-indexer safe use.
> * Start an actual RegionServer only have it register the AdminProtos Service
> only -- not ClientProtos and the Service that does Master interaction, etc.
> [I checked, this is not as easy to do as I at first thought -- St.Ack] Then
> have the hbase-indexer implement an AdminCoprocessor to override the
> replicateWALEntry method (the Admin CP implementation may need work). This
> would narrow the hbase-indexer exposure to that of the Admin Coprocessor
> Interface
> * Over in HBASE-10504, [~enis] suggested "... if we want to provide
> isolation for the replication services in hbase, we can have a simple host as
> another daemon which hosts the ReplicationEndpoint implementation. RS's will
> use a built-in RE to send the edits to this layer, and the host will delegate
> it to the RE implementation. The flow would be something like: RS --> RE
> inside RS --> Host daemon for RE --> Actual RE implementation --> third party
> system..."
>
> Other crazy notions occur including the setup of an Admin Interface
> Coprocessor Endpoint. A new ReplicationEndpoint would feed the replication
> stream to the remote cluster via the CPEP registered channel.
> But time is short. Hopefully we can figure something that will work in 2.0
> timeframe w/o too much code movement.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[ https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214095#comment-16214095 ] stack edited comment on HBASE-18846 at 10/22/17 4:44 AM: - bq. There's a lot of unrelated whitespace/formatting changes in the patch. I'll try to go through sometime and read it with a tool that can ignore those. Sorry about that. Let me try and remove some. This stuff needs a refactor badly. I can't help myself. bq. I guess we still check if the handler is enabled, but it looks less clean than the other options we're exposing. Replication startup is complicated (I've yet to figure it out). Default in hbase is to start Replication. In the hollowed-out HRegionServer, we need Replication so we put up a Sink to receive Replication. On enable/disable of Replication, I'd like to do that in another issue. We have a million services/chores/managers and they all work different. Ideally, they'd all work the same and the flag to stop/start it would be same pattern no matter what the Service; but that is TODO I'd say. Idea behind this issue is to get the hbase-indexer folks something they can work with; my guess is they will come back with other stuff they'd like to be handled in subsequent issues before beta-1. Long-term, this masterless HRegionServer looks like it'll be useful testing HRegionServer in Isolation. bq. On the health check, can we get into a false positive state where a thread is null but shouldn't be? Is it better to check the configuration source of truth there instead? Perhaps. I'd like some more experience with hollow-RegionServer deploy first. Can fix in follow-on. bq. In the TestStandaloneRegionServer, let's put some of the cleanup (like the join) in either a finally block or a @After method so that we don't pollute other tests if we fail. Done (I tried to add more tests but short-circuiting RPC'ing messes up ability to test stuff like whether the service enable/disable are having an effect.). was (Author: stack): bq. There's a lot of unrelated whitespace/formatting changes in the patch. I'll try to go through sometime and read it with a tool that can ignore those. Sorry about that. Let me try and remove some. This stuff needs a refactor badly. I can't help myself. bq. I guess we still check if the handler is enabled, but it looks less clean than the other options we're exposing. Replication startup is complicated (I've yet to figure it out). Default in hbase is to start Replication. In the hollowed-out HRegionServer, we need Replication so we put up a Sink to receive Replication. On enable/disable of Replication, I'd like to do that in another issue. We have a million services/chores/managers and they all work different. Ideally, they'd all work the same and the flag to stop/start it would be same pattern no matter what the Service; but that is TODO I'd day. Idea behind this issue is to get the hbase-indexer folks something they can work with; my guess is they will come back with other stuff they'd like to be handled in subsequent issues before beta-1. Long-term, this masterless HRegionServer looks like it'll be useful testing HRegionServer in Isolation. bq. On the health check, can we get into a false positive state where a thread is null but shouldn't be? Is it better to check the configuration source of truth there instead? Perhaps. I'd like some more experience with hollow-RegionServer deploy first. Can fix in follow-on. bq. In the TestStandaloneRegionServer, let's put some of the cleanup (like the join) in either a finally block or a @After method so that we don't pollute other tests if we fail. Done (I tried to add more tests but short-circuiting RPC'ing messes up ability to test). > Accommodate the hbase-indexer/lily/SEP consumer deploy-type > --- > > Key: HBASE-18846 > URL: https://issues.apache.org/jira/browse/HBASE-18846 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18846.master.001.patch, > HBASE-18846.master.002.patch, HBASE-18846.master.003.patch, > HBASE-18846.master.004.patch, HBASE-18846.master.005.patch, > IndexerConnection.java, hbase-site.xml, javadoc.txt > > > This is a follow-on from HBASE-10504, Define a Replication Interface. There > we defined a new, flexible replication endpoint for others to implement but > it did little to help the case of the lily hbase-indexer. This issue takes up > the case of the hbase-indexer. > The hbase-indexer poses to hbase as a 'fake' peer cluster (For why > hbase-indexer is implemented so, the advantage to having the indexing done in > a separate process set that can be independently scaled, can participate in > the same security realm,
[jira] [Updated] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[
https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-18846:
--
Attachment: HBASE-18846.master.005.patch
> Accommodate the hbase-indexer/lily/SEP consumer deploy-type
> ---
>
> Key: HBASE-18846
> URL: https://issues.apache.org/jira/browse/HBASE-18846
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18846.master.001.patch,
> HBASE-18846.master.002.patch, HBASE-18846.master.003.patch,
> HBASE-18846.master.004.patch, HBASE-18846.master.005.patch,
> IndexerConnection.java, hbase-site.xml, javadoc.txt
>
>
> This is a follow-on from HBASE-10504, Define a Replication Interface. There
> we defined a new, flexible replication endpoint for others to implement but
> it did little to help the case of the lily hbase-indexer. This issue takes up
> the case of the hbase-indexer.
> The hbase-indexer poses to hbase as a 'fake' peer cluster (For why
> hbase-indexer is implemented so, the advantage to having the indexing done in
> a separate process set that can be independently scaled, can participate in
> the same security realm, etc., see discussion in HBASE-10504). The
> hbase-indexer will start up a cut-down "RegionServer" processes that are just
> an instance of hbase RpcServer hosting an AdminProtos Service. They make
> themselves 'appear' to the Replication Source by hoisting up an ephemeral
> znode 'registering' as a RegionServer. The source cluster then streams
> WALEdits to the Admin Protos method:
> {code}
> public ReplicateWALEntryResponse replicateWALEntry(final RpcController
> controller,
> final ReplicateWALEntryRequest request) throws ServiceException {
> {code}
> The hbase-indexer relies on other hbase internals like Server so it can get a
> ZooKeeperWatcher instance and know the 'name' to use for this cut-down server.
> Thoughts on how to proceed include:
>
> * Better formalize its current digestion of hbase internals; make it so
> rpcserver is allowed to be used by others, etc. This would be hard to do
> given they use basics like Server, Protobuf serdes for WAL types, and
> AdminProtos Service. Any change in this wide API breaks (again)
> hbase-indexer. We have made a 'channel' for Coprocessor Endpoints so they
> continue to work though they use 'internal' types. They can use protos in
> hbase-protocol. hbase-protocol protos are in a limbo currently where they are
> sort-of 'public'; a TODO. Perhaps the hbase-indexer could do similar relying
> on the hbase-protocol (pb2.5) content and we could do something to reveal
> rpcserver and zk for hbase-indexer safe use.
> * Start an actual RegionServer only have it register the AdminProtos Service
> only -- not ClientProtos and the Service that does Master interaction, etc.
> [I checked, this is not as easy to do as I at first thought -- St.Ack] Then
> have the hbase-indexer implement an AdminCoprocessor to override the
> replicateWALEntry method (the Admin CP implementation may need work). This
> would narrow the hbase-indexer exposure to that of the Admin Coprocessor
> Interface
> * Over in HBASE-10504, [~enis] suggested "... if we want to provide
> isolation for the replication services in hbase, we can have a simple host as
> another daemon which hosts the ReplicationEndpoint implementation. RS's will
> use a built-in RE to send the edits to this layer, and the host will delegate
> it to the RE implementation. The flow would be something like: RS --> RE
> inside RS --> Host daemon for RE --> Actual RE implementation --> third party
> system..."
>
> Other crazy notions occur including the setup of an Admin Interface
> Coprocessor Endpoint. A new ReplicationEndpoint would feed the replication
> stream to the remote cluster via the CPEP registered channel.
> But time is short. Hopefully we can figure something that will work in 2.0
> timeframe w/o too much code movement.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[ https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214095#comment-16214095 ] stack edited comment on HBASE-18846 at 10/22/17 4:23 AM: - bq. There's a lot of unrelated whitespace/formatting changes in the patch. I'll try to go through sometime and read it with a tool that can ignore those. Sorry about that. Let me try and remove some. This stuff needs a refactor badly. I can't help myself. bq. I guess we still check if the handler is enabled, but it looks less clean than the other options we're exposing. Replication startup is complicated (I've yet to figure it out). Default in hbase is to start Replication. In the hollowed-out HRegionServer, we need Replication so we put up a Sink to receive Replication. On enable/disable of Replication, I'd like to do that in another issue. We have a million services/chores/managers and they all work different. Ideally, they'd all work the same and the flag to stop/start it would be same pattern no matter what the Service; but that is TODO I'd day. Idea behind this issue is to get the hbase-indexer folks something they can work with; my guess is they will come back with other stuff they'd like to be handled in subsequent issues before beta-1. Long-term, this masterless HRegionServer looks like it'll be useful testing HRegionServer in Isolation. bq. On the health check, can we get into a false positive state where a thread is null but shouldn't be? Is it better to check the configuration source of truth there instead? Perhaps. I'd like some more experience with hollow-RegionServer deploy first. Can fix in follow-on. bq. In the TestStandaloneRegionServer, let's put some of the cleanup (like the join) in either a finally block or a @After method so that we don't pollute other tests if we fail. Done (I tried to add more tests but short-circuiting RPC'ing messes up ability to test). was (Author: stack): bq. There's a lot of unrelated whitespace/formatting changes in the patch. I'll try to go through sometime and read it with a tool that can ignore those. Sorry about that. Let me try and remove some. This stuff needs a refactor badly. I can't help myself. bq. I guess we still check if the handler is enabled, but it looks less clean than the other options we're exposing. Replication startup is complicated (I've yet to figure it out). Default in hbase is to start Replication. In the hollowed-out HRegionServer, we need Replication so we put up a Sink to receive Replication. On enable/disable of Replication, I'd like to do that in another issue. We have a million services/chores/managers and they all work different. Ideally, they'd all work the same and the flag to stop/start it would be same pattern no matter what the Service; but that is TODO I'd day. Idea behind this issue is to get the hbase-indexer folks something they can work with; my guess is they will come back with other stuff they'd like to be handled in subsequent issues before beta-1. Long-term, this masterless HRegionServer looks like it'll be useful testing HRegionServer in Isolation. bq. On the health check, can we get into a false positive state where a thread is null but shouldn't be? Is it better to check the configuration source of truth there instead? Perhaps. I'd like some more experience with hollow-RegionServer deploy first. Can fix in follow-on. bq. In the TestStandaloneRegionServer, let's put some of the cleanup (like the join) in either a finally block or a @After method so that we don't pollute other tests if we fail. Done. Added more tests too... for some of the other configs introduced here. > Accommodate the hbase-indexer/lily/SEP consumer deploy-type > --- > > Key: HBASE-18846 > URL: https://issues.apache.org/jira/browse/HBASE-18846 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18846.master.001.patch, > HBASE-18846.master.002.patch, HBASE-18846.master.003.patch, > HBASE-18846.master.004.patch, IndexerConnection.java, hbase-site.xml, > javadoc.txt > > > This is a follow-on from HBASE-10504, Define a Replication Interface. There > we defined a new, flexible replication endpoint for others to implement but > it did little to help the case of the lily hbase-indexer. This issue takes up > the case of the hbase-indexer. > The hbase-indexer poses to hbase as a 'fake' peer cluster (For why > hbase-indexer is implemented so, the advantage to having the indexing done in > a separate process set that can be independently scaled, can participate in > the same security realm, etc., see discussion in HBASE-10504). The > hbase-indexer will start up a cut-down "RegionServer" processes
[jira] [Comment Edited] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[ https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214095#comment-16214095 ] stack edited comment on HBASE-18846 at 10/22/17 3:37 AM: - bq. There's a lot of unrelated whitespace/formatting changes in the patch. I'll try to go through sometime and read it with a tool that can ignore those. Sorry about that. Let me try and remove some. This stuff needs a refactor badly. I can't help myself. bq. I guess we still check if the handler is enabled, but it looks less clean than the other options we're exposing. Replication startup is complicated (I've yet to figure it out). Default in hbase is to start Replication. In the hollowed-out HRegionServer, we need Replication so we put up a Sink to receive Replication. On enable/disable of Replication, I'd like to do that in another issue. We have a million services/chores/managers and they all work different. Ideally, they'd all work the same and the flag to stop/start it would be same pattern no matter what the Service; but that is TODO I'd day. Idea behind this issue is to get the hbase-indexer folks something they can work with; my guess is they will come back with other stuff they'd like to be handled in subsequent issues before beta-1. Long-term, this masterless HRegionServer looks like it'll be useful testing HRegionServer in Isolation. bq. On the health check, can we get into a false positive state where a thread is null but shouldn't be? Is it better to check the configuration source of truth there instead? Perhaps. I'd like some more experience with hollow-RegionServer deploy first. Can fix in follow-on. bq. In the TestStandaloneRegionServer, let's put some of the cleanup (like the join) in either a finally block or a @After method so that we don't pollute other tests if we fail. Done. Added more tests too... for some of the other configs introduced here. was (Author: stack): bq. There's a lot of unrelated whitespace/formatting changes in the patch. I'll try to go through sometime and read it with a tool that can ignore those. Sorry about that. Let me try and remove some. This stuff needs a refactor. I can't help myself. bq. I guess we still check if the handler is enabled, but it looks less clean than the other options we're exposing. On Replication startup, I moved it under general startServices for now -- it'll be off in hollow-HRegionServer deploy ... Moved webui OUT of startServices because that already has its own enable/disable (Idea behind this issue is to get the hbase-indexer folks something they can work with; my guess is they will come back with other stuff they'd like to be handled in subsequent issues before beta-1. Long-term, this masterless HRegionServer looks like it'll be useful testing HRegionServer in Isolation. And whole world of start/stop services/managers/etc. is in bad need of cleanup. TODO). bq. On the health check, can we get into a false positive state where a thread is null but shouldn't be? Is it better to check the configuration source of truth there instead? Perhaps. I'd like some more experience with hollow-RegionServer deploy first. Can fix in follow-on. bq. In the TestStandaloneRegionServer, let's put some of the cleanup (like the join) in either a finally block or a @After method so that we don't pollute other tests if we fail. Done. Added more tests too... for some of the other configs introduced here. > Accommodate the hbase-indexer/lily/SEP consumer deploy-type > --- > > Key: HBASE-18846 > URL: https://issues.apache.org/jira/browse/HBASE-18846 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18846.master.001.patch, > HBASE-18846.master.002.patch, HBASE-18846.master.003.patch, > HBASE-18846.master.004.patch, IndexerConnection.java, hbase-site.xml, > javadoc.txt > > > This is a follow-on from HBASE-10504, Define a Replication Interface. There > we defined a new, flexible replication endpoint for others to implement but > it did little to help the case of the lily hbase-indexer. This issue takes up > the case of the hbase-indexer. > The hbase-indexer poses to hbase as a 'fake' peer cluster (For why > hbase-indexer is implemented so, the advantage to having the indexing done in > a separate process set that can be independently scaled, can participate in > the same security realm, etc., see discussion in HBASE-10504). The > hbase-indexer will start up a cut-down "RegionServer" processes that are just > an instance of hbase RpcServer hosting an AdminProtos Service. They make > themselves 'appear' to the Replication Source by hoisting up an ephemeral > znode 'registering' as a RegionServer. The source
[jira] [Commented] (HBASE-19019) QA fails on hbase-thrift module with timeout
[
https://issues.apache.org/jira/browse/HBASE-19019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214166#comment-16214166
]
Hadoop QA commented on HBASE-19019:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
10s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
36s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
21s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
23s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
54s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
11s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
38s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
14s{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 46s{color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3.
{color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
38s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}582m 50s{color}
| {color:red} hbase-thrift in the patch failed. {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}614m 31s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:f29f170 |
| JIRA Issue | HBASE-19019 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893422/HBASE-19019.branch-1.2.dummy.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 699aa532e31b 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | branch-1.2 / f29f170 |
| Default Java | 1.7.0_151 |
| findbugs | v3.0.0 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/9307/artifact/patchprocess/patch-unit-hbase-thrift.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9307/testReport/ |
| modules | C: hbase-thrift U:
[jira] [Updated] (HBASE-19053) Split out o.a.h.h.http from hbase-server into a separate module
[ https://issues.apache.org/jira/browse/HBASE-19053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-19053: - Attachment: HBASE-19053.master.003.patch > Split out o.a.h.h.http from hbase-server into a separate module > --- > > Key: HBASE-19053 > URL: https://issues.apache.org/jira/browse/HBASE-19053 > Project: HBase > Issue Type: Bug >Reporter: Appy >Assignee: Appy > Attachments: HBASE-19053.master.001.patch, > HBASE-19053.master.002.patch, HBASE-19053.master.003.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19057) Merge branch HBASE-18410 to master branch
[
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214156#comment-16214156
]
Hadoop QA commented on HBASE-19057:
---
| (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} docker {color} | {color:red} 12m
17s{color} | {color:red} Docker failed to build yetus/hbase:5d60123. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-19057 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893420/HBASE-19057-HBASE-18410.v1.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9310/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Merge branch HBASE-18410 to master branch
> -
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
> Issue Type: Sub-task
> Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch
>
>
> Open this issue to fix conflict , run HadoopQA and gather other feedback.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19057) Merge branch HBASE-18410 to master branch
[ https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-19057: - Status: Patch Available (was: Open) > Merge branch HBASE-18410 to master branch > - > > Key: HBASE-19057 > URL: https://issues.apache.org/jira/browse/HBASE-19057 > Project: HBase > Issue Type: Sub-task > Components: Filters >Reporter: Zheng Hu >Assignee: Zheng Hu > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19057-HBASE-18410.v1.patch > > > Open this issue to fix conflict , run HadoopQA and gather other feedback. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19057) Merge branch HBASE-18410 to master branch
[
https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214152#comment-16214152
]
Zheng Hu commented on HBASE-19057:
--
If we have following change:
{code}
diff --git
a/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterListWithOR.java
b/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterListWithOR.java
index 6ee301a..f44b62a 100644
---
a/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterListWithOR.java
+++
b/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterListWithOR.java
@@ -317,6 +317,7 @@ public class FilterListWithOR extends FilterListBase {
Filter filter = filters.get(i);
if (!filter.filterRowKey(rowKey, offset, length)) {
retVal = false;
+return retVal;
}
}
return retVal;
@@ -332,6 +333,7 @@ public class FilterListWithOR extends FilterListBase {
Filter filter = filters.get(i);
if (!filter.filterRowKey(firstRowCell)) {
retVal = false;
+return retVal;
}
}
return retVal;
{code}
Then, UT such as testFilterListTwoFiltersMustPassOne will fail. You can have
a try :-)
> Merge branch HBASE-18410 to master branch
> -
>
> Key: HBASE-19057
> URL: https://issues.apache.org/jira/browse/HBASE-19057
> Project: HBase
> Issue Type: Sub-task
> Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19057-HBASE-18410.v1.patch
>
>
> Open this issue to fix conflict , run HadoopQA and gather other feedback.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18950) Remove Optional parameters in AsyncAdmin interface
[ https://issues.apache.org/jira/browse/HBASE-18950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-18950: --- Attachment: HBASE-18950.master.007.patch > Remove Optional parameters in AsyncAdmin interface > -- > > Key: HBASE-18950 > URL: https://issues.apache.org/jira/browse/HBASE-18950 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Blocker > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18950.master.001.patch, > HBASE-18950.master.002.patch, HBASE-18950.master.003.patch, > HBASE-18950.master.004.patch, HBASE-18950.master.005.patch, > HBASE-18950.master.005.patch, HBASE-18950.master.006.patch, > HBASE-18950.master.007.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214143#comment-16214143 ] Lars Hofhansl commented on HBASE-15631: --- Cool! > Backport Regionserver Groups (HBASE-6721) to branch-1 > -- > > Key: HBASE-15631 > URL: https://issues.apache.org/jira/browse/HBASE-15631 > Project: HBase > Issue Type: New Feature >Affects Versions: 1.4.0 >Reporter: Francis Liu >Assignee: Andrew Purtell > Fix For: 1.4.0, 1.5.0 > > Attachments: HBASE-15631-branch-1.patch, HBASE-15631-branch-1.patch, > HBASE-15631.branch-1.patch, HBASE-15631.patch > > > Based on dev list discussion backporting region server group should not be an > issue as it does not: 1. destabilize the code. 2. cause backward > incompatibility. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18873) Hide protobufs in GlobalQuotaSettings
[
https://issues.apache.org/jira/browse/HBASE-18873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214138#comment-16214138
]
Hadoop QA commented on HBASE-18873:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 17m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
12s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
31s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
36s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
24s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
38s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
54s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
47s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
10s{color} | {color:green} branch-2 passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
24s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
31s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 800 line(s) that end in whitespace. Use
git apply --whitespace=fix <>. Refer
https://git-scm.com/docs/git-apply {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
14s{color} | {color:red} The patch 384 line(s) with tabs. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
47s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
55m 21s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
7s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}114m
27s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
26s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}226m 14s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8afa3e |
| JIRA Issue | HBASE-18873 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893432/HBASE-18873.003.branch-2.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux b473a0f3c95e 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 x86_64
[jira] [Commented] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214132#comment-16214132 ] Hudson commented on HBASE-19007: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3927 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3927/]) HBASE-19007 Align Services Interfaces in Master and RegionServer (stack: rev 38879fb3ffa88ca95b15c61656a92e72c0ed996f) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSyncUp.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlLists.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestActiveMasterManager.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitLogWorker.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityController.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Connection.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/MasterSpaceQuotaObserver.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterCoprocessorHost.java * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoreRegionCoprocessor.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/Server.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestHFileLinkCleaner.java * (add) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoreCoprocessor.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestOpenTableInCoprocessor.java * (add) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/HasRegionServerServices.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/RegionCoprocessorEnvironment.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/BaseEnvironment.java * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorShortCircuitRPC.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/token/TestTokenAuthentication.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/QuotaCache.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorInterface.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestHFileCleaner.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestWALLockup.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestReplicaWithCluster.java * (edit) hbase-endpoint/src/main/java/org/apache/hadoop/hbase/security/access/SecureBulkLoadEndpoint.java * (delete) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CoprocessorRegionServerServices.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityLabelServiceManager.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcServer.java * (edit) hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupAdminEndpoint.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionServerServices.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/MockNoopMasterServices.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerAbort.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/RegionServerCoprocessorEnvironment.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/MockRegionServer.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/util/MockServer.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationStateZKImpl.java * (add) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/HasMasterServices.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/replication/regionserver/TestReplicationSourceManager.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationObserver.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionUtils.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/MasterCoprocessorEnvironment.java * (edit)
[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214133#comment-16214133
]
Hudson commented on HBASE-18824:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3927 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/3927/])
HBASE-18824 Add meaningful comment to HConstants.LATEST_TIMESTAMP to (chia7712:
rev 2ee8690b47763fd0ed97d47713b1c516633f597b)
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch,
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch,
> HBASE-18824.master.005.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214129#comment-16214129 ] Hudson commented on HBASE-19007: FAILURE: Integrated in Jenkins build HBase-2.0 #727 (See [https://builds.apache.org/job/HBase-2.0/727/]) HBASE-19007 Align Services Interfaces in Master and RegionServer (stack: rev 00f2b18148c95e9db67fc3b73dbc6c7dceea9750) * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoreRegionCoprocessor.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionServerCoprocessorExceptionWithAbort.java * (edit) hbase-thrift/src/test/java/org/apache/hadoop/hbase/thrift/ErrorThrowingGetObserver.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/MockRegionServer.java * (add) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/HasMasterServices.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/MasterSpaceQuotaObserver.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitLogWorker.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionUtils.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/MasterCoprocessorEnvironment.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityLabelServiceManager.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/replication/regionserver/TestReplicationSourceManager.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionObserverStacking.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestHFileCleaner.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/Server.java * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoreRegionServerCoprocessor.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/util/MockServer.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterCoprocessorHost.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestHFileLinkCleaner.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/BaseEnvironment.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/RegionServerCoprocessorEnvironment.java * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorShortCircuitRPC.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionServerAbort.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessControlLists.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/token/TokenProvider.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/MockRegionServerServices.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/token/TestTokenAuthentication.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHeapMemoryManager.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationStateHBaseImpl.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Connection.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestReplicaWithCluster.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestReplicationHFileCleaner.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestLogsCleaner.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationObserver.java * (add) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoreCoprocessor.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSyncUp.java * (delete) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CoprocessorRegionServerServices.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/QuotaCache.java * (add) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/HasRegionServerServices.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/DefaultVisibilityLabelServiceImpl.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionServerServices.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorInterface.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterServices.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RpcServer.java * (edit)
[jira] [Updated] (HBASE-18950) Remove Optional parameters in AsyncAdmin interface
[ https://issues.apache.org/jira/browse/HBASE-18950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-18950: --- Attachment: (was: HBASE-18950.master.006.patch) > Remove Optional parameters in AsyncAdmin interface > -- > > Key: HBASE-18950 > URL: https://issues.apache.org/jira/browse/HBASE-18950 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Blocker > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18950.master.001.patch, > HBASE-18950.master.002.patch, HBASE-18950.master.003.patch, > HBASE-18950.master.004.patch, HBASE-18950.master.005.patch, > HBASE-18950.master.005.patch, HBASE-18950.master.006.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18950) Remove Optional parameters in AsyncAdmin interface
[ https://issues.apache.org/jira/browse/HBASE-18950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-18950: --- Attachment: HBASE-18950.master.006.patch > Remove Optional parameters in AsyncAdmin interface > -- > > Key: HBASE-18950 > URL: https://issues.apache.org/jira/browse/HBASE-18950 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Blocker > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18950.master.001.patch, > HBASE-18950.master.002.patch, HBASE-18950.master.003.patch, > HBASE-18950.master.004.patch, HBASE-18950.master.005.patch, > HBASE-18950.master.005.patch, HBASE-18950.master.006.patch, > HBASE-18950.master.006.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18824:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Thanks for the patch. [~water]
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch,
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch,
> HBASE-18824.master.005.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18824:
---
Fix Version/s: 2.0.0
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch,
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch,
> HBASE-18824.master.005.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[
https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-18846:
--
Release Note:
Makes it so hbase-indexer/lily can move off dependence on internal APIs and
instead move to public APIs.
Adds being able to disable near-all HRegionServer services. This along with an
existing plugin mechanism which allows configuring the RegionServer to host an
alternate Connection implementation, makes it so we can put up a cluster of
hollowed-out HRegionServers purposed to pose as a Replication Sink for a source
HBase Cluster (Users do not need to figure our RPC, our PB encodings, build a
distributed service, etc.). In the alternate supplied Connection
implementation, hbase-indexer would install its own code to catch the
Replication.
Below and attached are sample hbase-server.xml files and alternate Connection
implementations. To start up an HRegionServer as a sink, first make sure there
is a ZooKeeper ensemble we can talk to. If none, just start one:
{code}
./bin/hbase-daemon.sh start zookeeper
{code}
To start up a single RegionServer, put in place the below sample hbase-site.xml
and a derviative of the below IndexerConnection on the CLASSPATH, and then
start the RegionServer:
{code}
./bin/hbase-daemon.sh start org.apache.hadoop.hbase.regionserver.HRegionServer
{code}
Stdout and Stderr will go into files under configured logs directory. Browse to
localhost:16030 to find webui (unless disabled).
DETAILS
This patch adds configuration to disable RegionServer internal Services,
Managers, Caches, etc., starting up.
By default a RegionServer starts up an Admin and Client Service. To disable
either or both, use the below booleans:
{code}
hbase.regionserver.admin.service
hbase.regionserver.client.service
{code}
Both default true.
To make a HRegionServer startup and stay up without expecting to communicate
with a master, set the below boolean to false:
{code}
hbase.masterless
{code]
Default is false.
h3. Sample hbase-site.xml that disables internal HRegionServer Services
Below is an example hbase-site.xml that turns off most Services and that then
installs an alternate Connection implementation, one that is nulled out in all
regards except in being able to return a "Table" that can catch a Replication
Stream in its {code}batch(List actions, Object[] results){code}
method. i.e. what the hbase-indexer wants. I also add the example alternate
Connection implementation below (both of these files are also attached to this
issue). Expects there to be an up and running zookeeper ensemble.
{code}
hbase.cluster.distributed
true
hbase.client.connection.impl
org.apache.hadoop.hbase.client.IndexerConnection
A customs connection implementation just so we can interject
our
own Table class, one that has an override for the batch call which
receives
the replication stream edits; i.e. it is called by the replication sink
#replicateEntries method.
hbase.regionserver.admin.service
false
Do NOT stand up an Admin Service Interface on RPC
hbase.regionserver.client.service
false
Do NOT stand up a client-facing Service on RPC
hbase.wal.provider
org.apache.hadoop.hbase.wal.DisabledWALProvider
Set WAL service to be the null WAL
hbase.regionserver.workers
false
Turn off all background workers, log splitters, executors,
etc.
hfile.block.cache.size
0.0001
Turn off block cache completely
hbase.mob.file.cache.size
0
Disable MOB cache.
hbase.masterless
true
Do not expect Master in cluster.
hbase.regionserver.metahandler.count
1
How many priority handlers to run; we probably need none.
Default is 20 which is too much on a server like this.
hbase.regionserver.replication.handler.count
1
How many replication handlers to run; we probably need none.
Default is 3 which is too much on a server like this.
hbase.regionserver.handler.count
10
How many default handlers to run; tie to # of CPUs.
Default is 30 which is too much on a server like this.
hbase.ipc.server.read.threadpool.size
3
How many Listener request reaaders to run; tie to a portion #
of CPUs (1/4?).
Default is 10 which is too much on a server like this.
{code}
h2. Sample Connection Implementation
Has call-out for where an hbase-indexer would insert its capture code.
{code}
package org.apache.hadoop.hbase.client;
import com.google.protobuf.Descriptors;
import com.google.protobuf.Message;
import com.google.protobuf.Service;
import com.google.protobuf.ServiceException;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.hbase.CompareOperator;
import org.apache.hadoop.hbase.HTableDescriptor;
import org.apache.hadoop.hbase.TableName;
import
[jira] [Comment Edited] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[
https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214095#comment-16214095
]
stack edited comment on HBASE-18846 at 10/21/17 8:50 PM:
-
bq. There's a lot of unrelated whitespace/formatting changes in the patch. I'll
try to go through sometime and read it with a tool that can ignore those.
Sorry about that. Let me try and remove some. This stuff needs a refactor. I
can't help myself.
bq. I guess we still check if the handler is enabled, but it looks less clean
than the other options we're exposing.
On Replication startup, I moved it under general startServices for now -- it'll
be off in hollow-HRegionServer deploy ... Moved webui OUT of startServices
because that already has its own enable/disable (Idea behind this issue is to
get the hbase-indexer folks something they can work with; my guess is they will
come back with other stuff they'd like to be handled in subsequent issues
before beta-1. Long-term, this masterless HRegionServer looks like it'll be
useful testing HRegionServer in Isolation. And whole world of start/stop
services/managers/etc. is in bad need of cleanup. TODO).
bq. On the health check, can we get into a false positive state where a thread
is null but shouldn't be? Is it better to check the configuration source of
truth there instead?
Perhaps. I'd like some more experience with hollow-RegionServer deploy first.
Can fix in follow-on.
bq. In the TestStandaloneRegionServer, let's put some of the cleanup (like the
join) in either a finally block or a @After method so that we don't pollute
other tests if we fail.
Done. Added more tests too... for some of the other configs introduced here.
was (Author: stack):
bq. There's a lot of unrelated whitespace/formatting changes in the patch. I'll
try to go through sometime and read it with a tool that can ignore those.
Sorry about that. Let me try and remove some. This stuff needs a refactor. I
can't help myself.
bq. I guess we still check if the handler is enabled, but it looks less clean
than the other options we're exposing.
On Replication startup, see note at tail of setupWALAndReplication. There is
some circular dependency between Replication and WAL. I'd suggest untangle is
outside scope of this issue (Idea behind this issue is to get the hbase-indexer
folks something they can work with; my guess is they will come back with other
stuff they'd like to be handled in subsequent issues before beta-1. Long-term,
this masterless HRegionServer looks like it'll be useful testing HRegionServer
in Isolation. TODO).
bq. On the health check, can we get into a false positive state where a thread
is null but shouldn't be? Is it better to check the configuration source of
truth there instead?
Perhaps. I'd like some more experience with hollow-RegionServer deploy first.
Can fix in follow-on.
bq. In the TestStandaloneRegionServer, let's put some of the cleanup (like the
join) in either a finally block or a @After method so that we don't pollute
other tests if we fail.
Done. Added more tests too... for some of the other configs introduced here.
> Accommodate the hbase-indexer/lily/SEP consumer deploy-type
> ---
>
> Key: HBASE-18846
> URL: https://issues.apache.org/jira/browse/HBASE-18846
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18846.master.001.patch,
> HBASE-18846.master.002.patch, HBASE-18846.master.003.patch,
> HBASE-18846.master.004.patch, IndexerConnection.java, hbase-site.xml,
> javadoc.txt
>
>
> This is a follow-on from HBASE-10504, Define a Replication Interface. There
> we defined a new, flexible replication endpoint for others to implement but
> it did little to help the case of the lily hbase-indexer. This issue takes up
> the case of the hbase-indexer.
> The hbase-indexer poses to hbase as a 'fake' peer cluster (For why
> hbase-indexer is implemented so, the advantage to having the indexing done in
> a separate process set that can be independently scaled, can participate in
> the same security realm, etc., see discussion in HBASE-10504). The
> hbase-indexer will start up a cut-down "RegionServer" processes that are just
> an instance of hbase RpcServer hosting an AdminProtos Service. They make
> themselves 'appear' to the Replication Source by hoisting up an ephemeral
> znode 'registering' as a RegionServer. The source cluster then streams
> WALEdits to the Admin Protos method:
> {code}
> public ReplicateWALEntryResponse replicateWALEntry(final RpcController
> controller,
> final ReplicateWALEntryRequest request) throws ServiceException {
> {code}
> The hbase-indexer relies on other hbase internals like Server so
[jira] [Updated] (HBASE-18873) Hide protobufs in GlobalQuotaSettings
[ https://issues.apache.org/jira/browse/HBASE-18873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-18873: --- Attachment: HBASE-18873.003.branch-2.patch Retrying .003. The surefire forks were killed/failed. > Hide protobufs in GlobalQuotaSettings > - > > Key: HBASE-18873 > URL: https://issues.apache.org/jira/browse/HBASE-18873 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18873.001.branch-2.patch, > HBASE-18873.002.branch-2.patch, HBASE-18873.003.branch-2.patch > > > HBASE-18807 cleaned up direct protobuf use in the Coprocessor APIs for > quota-related functions. However, one new POJO introduced to hide these > protocol buffers still exposes PBs via some methods. > We should try to hide those as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18873) Hide protobufs in GlobalQuotaSettings
[ https://issues.apache.org/jira/browse/HBASE-18873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-18873: --- Attachment: (was: HBASE-18873.003.branch-2.patch) > Hide protobufs in GlobalQuotaSettings > - > > Key: HBASE-18873 > URL: https://issues.apache.org/jira/browse/HBASE-18873 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18873.001.branch-2.patch, > HBASE-18873.002.branch-2.patch, HBASE-18873.003.branch-2.patch > > > HBASE-18807 cleaned up direct protobuf use in the Coprocessor APIs for > quota-related functions. However, one new POJO introduced to hide these > protocol buffers still exposes PBs via some methods. > We should try to hide those as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19000) Group multiple block cache clear requests per server
[ https://issues.apache.org/jira/browse/HBASE-19000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-19000: --- Labels: rpc (was: ) > Group multiple block cache clear requests per server > > > Key: HBASE-19000 > URL: https://issues.apache.org/jira/browse/HBASE-19000 > Project: HBase > Issue Type: Sub-task >Reporter: Ted Yu > Labels: rpc > > During the review of HBASE-18624, I brought up the following: > There would be multiple regions on the same server whose block cache is to be > cleared. > Multiple block cache clear requests should be grouped per server to reduce > the number of RPC calls. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18942) hbase-hadoop2-compat module ignores hadoop-3 profile
[
https://issues.apache.org/jira/browse/HBASE-18942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-18942:
---
Labels: build (was: )
> hbase-hadoop2-compat module ignores hadoop-3 profile
>
>
> Key: HBASE-18942
> URL: https://issues.apache.org/jira/browse/HBASE-18942
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
> Labels: build
>
> In hbase-hadoop2-compat/pom.xml :
> {code}
>
> org.apache.hadoop
> hadoop-common
> ${hadoop-two.version}
>
> {code}
> The version for hadoop-common defaults to hadoop-two.
> This means that when hadoop-3.0 profile is used, hadoop-three.version would
> be ignored.
> The following error would be observed:
> {code}
> Caused by: java.util.ServiceConfigurationError:
> org.apache.hadoop.hbase.zookeeper.MetricsZooKeeperSource: Provider
> org.apache.hadoop.hbase.zookeeper.MetricsZooKeeperSourceImpl could not be
> instantiated
> at java.util.ServiceLoader.fail(ServiceLoader.java:232)
> at java.util.ServiceLoader.access$100(ServiceLoader.java:185)
> at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:384)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at
> org.apache.hadoop.hbase.CompatibilitySingletonFactory.getInstance(CompatibilitySingletonFactory.java:59)
> ... 34 more
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> com.sun.proxy.$Proxy17
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:739)
> at
> org.apache.commons.configuration2.builder.fluent.Parameters.createParametersProxy(Parameters.java:294)
> at
> org.apache.commons.configuration2.builder.fluent.Parameters.fileBased(Parameters.java:185)
> at
> org.apache.commons.configuration2.builder.fluent.Configurations.fileParams(Configurations.java:602)
> at
> org.apache.commons.configuration2.builder.fluent.Configurations.fileParams(Configurations.java:638)
> at
> org.apache.commons.configuration2.builder.fluent.Configurations.fileBasedBuilder(Configurations.java:164)
> at
> org.apache.commons.configuration2.builder.fluent.Configurations.propertiesBuilder(Configurations.java:264)
> at
> org.apache.hadoop.metrics2.impl.MetricsConfig.loadFirst(MetricsConfig.java:115)
> at
> org.apache.hadoop.metrics2.impl.MetricsConfig.create(MetricsConfig.java:98)
> at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.configure(MetricsSystemImpl.java:478)
> at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.start(MetricsSystemImpl.java:188)
> at
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.init(MetricsSystemImpl.java:163)
> at
> org.apache.hadoop.metrics2.lib.DefaultMetricsSystem.init(DefaultMetricsSystem.java:62)
> at
> org.apache.hadoop.metrics2.lib.DefaultMetricsSystem.initialize(DefaultMetricsSystem.java:58)
> at
> org.apache.hadoop.hbase.metrics.BaseSourceImpl$DefaultMetricsSystemInitializer.init(BaseSourceImpl.java:51)
> at
> org.apache.hadoop.hbase.metrics.BaseSourceImpl.(BaseSourceImpl.java:112)
> at
> org.apache.hadoop.hbase.zookeeper.MetricsZooKeeperSourceImpl.(MetricsZooKeeperSourceImpl.java:56)
> at
> org.apache.hadoop.hbase.zookeeper.MetricsZooKeeperSourceImpl.(MetricsZooKeeperSourceImpl.java:51)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[
https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214095#comment-16214095
]
stack commented on HBASE-18846:
---
bq. There's a lot of unrelated whitespace/formatting changes in the patch. I'll
try to go through sometime and read it with a tool that can ignore those.
Sorry about that. Let me try and remove some. This stuff needs a refactor. I
can't help myself.
bq. I guess we still check if the handler is enabled, but it looks less clean
than the other options we're exposing.
On Replication startup, see note at tail of setupWALAndReplication. There is
some circular dependency between Replication and WAL. I'd suggest untangle is
outside scope of this issue (Idea behind this issue is to get the hbase-indexer
folks something they can work with; my guess is they will come back with other
stuff they'd like to be handled in subsequent issues before beta-1. Long-term,
this masterless HRegionServer looks like it'll be useful testing HRegionServer
in Isolation. TODO).
bq. On the health check, can we get into a false positive state where a thread
is null but shouldn't be? Is it better to check the configuration source of
truth there instead?
Perhaps. I'd like some more experience with hollow-RegionServer deploy first.
Can fix in follow-on.
bq. In the TestStandaloneRegionServer, let's put some of the cleanup (like the
join) in either a finally block or a @After method so that we don't pollute
other tests if we fail.
Done. Added more tests too... for some of the other configs introduced here.
> Accommodate the hbase-indexer/lily/SEP consumer deploy-type
> ---
>
> Key: HBASE-18846
> URL: https://issues.apache.org/jira/browse/HBASE-18846
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18846.master.001.patch,
> HBASE-18846.master.002.patch, HBASE-18846.master.003.patch,
> HBASE-18846.master.004.patch, IndexerConnection.java, hbase-site.xml,
> javadoc.txt
>
>
> This is a follow-on from HBASE-10504, Define a Replication Interface. There
> we defined a new, flexible replication endpoint for others to implement but
> it did little to help the case of the lily hbase-indexer. This issue takes up
> the case of the hbase-indexer.
> The hbase-indexer poses to hbase as a 'fake' peer cluster (For why
> hbase-indexer is implemented so, the advantage to having the indexing done in
> a separate process set that can be independently scaled, can participate in
> the same security realm, etc., see discussion in HBASE-10504). The
> hbase-indexer will start up a cut-down "RegionServer" processes that are just
> an instance of hbase RpcServer hosting an AdminProtos Service. They make
> themselves 'appear' to the Replication Source by hoisting up an ephemeral
> znode 'registering' as a RegionServer. The source cluster then streams
> WALEdits to the Admin Protos method:
> {code}
> public ReplicateWALEntryResponse replicateWALEntry(final RpcController
> controller,
> final ReplicateWALEntryRequest request) throws ServiceException {
> {code}
> The hbase-indexer relies on other hbase internals like Server so it can get a
> ZooKeeperWatcher instance and know the 'name' to use for this cut-down server.
> Thoughts on how to proceed include:
>
> * Better formalize its current digestion of hbase internals; make it so
> rpcserver is allowed to be used by others, etc. This would be hard to do
> given they use basics like Server, Protobuf serdes for WAL types, and
> AdminProtos Service. Any change in this wide API breaks (again)
> hbase-indexer. We have made a 'channel' for Coprocessor Endpoints so they
> continue to work though they use 'internal' types. They can use protos in
> hbase-protocol. hbase-protocol protos are in a limbo currently where they are
> sort-of 'public'; a TODO. Perhaps the hbase-indexer could do similar relying
> on the hbase-protocol (pb2.5) content and we could do something to reveal
> rpcserver and zk for hbase-indexer safe use.
> * Start an actual RegionServer only have it register the AdminProtos Service
> only -- not ClientProtos and the Service that does Master interaction, etc.
> [I checked, this is not as easy to do as I at first thought -- St.Ack] Then
> have the hbase-indexer implement an AdminCoprocessor to override the
> replicateWALEntry method (the Admin CP implementation may need work). This
> would narrow the hbase-indexer exposure to that of the Admin Coprocessor
> Interface
> * Over in HBASE-10504, [~enis] suggested "... if we want to provide
> isolation for the replication services in hbase, we can have a simple host as
> another daemon which hosts the ReplicationEndpoint implementation. RS's will
> use a built-in
[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214086#comment-16214086
]
Chia-Ping Tsai commented on HBASE-18824:
Will commit it later
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch,
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch,
> HBASE-18824.master.005.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[
https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213760#comment-16213760
]
stack edited comment on HBASE-18846 at 10/21/17 7:45 PM:
-
No. Did not mean to include the hbase-site and sample indexer. Thanks.
Fixed the class comment (s/emasculated/hollow/).
Will put up new patch to address your other comments. Thanks for taking a look
[~mdrob]
was (Author: stack):
No. Did not mean to include the hbase-site and sample indexer. Thanks.
Fixed the release note (s/emasculated/hollow/).
Will put up new patch to address your other comments. Thanks for taking a look
[~mdrob]
> Accommodate the hbase-indexer/lily/SEP consumer deploy-type
> ---
>
> Key: HBASE-18846
> URL: https://issues.apache.org/jira/browse/HBASE-18846
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18846.master.001.patch,
> HBASE-18846.master.002.patch, HBASE-18846.master.003.patch,
> HBASE-18846.master.004.patch, IndexerConnection.java, hbase-site.xml,
> javadoc.txt
>
>
> This is a follow-on from HBASE-10504, Define a Replication Interface. There
> we defined a new, flexible replication endpoint for others to implement but
> it did little to help the case of the lily hbase-indexer. This issue takes up
> the case of the hbase-indexer.
> The hbase-indexer poses to hbase as a 'fake' peer cluster (For why
> hbase-indexer is implemented so, the advantage to having the indexing done in
> a separate process set that can be independently scaled, can participate in
> the same security realm, etc., see discussion in HBASE-10504). The
> hbase-indexer will start up a cut-down "RegionServer" processes that are just
> an instance of hbase RpcServer hosting an AdminProtos Service. They make
> themselves 'appear' to the Replication Source by hoisting up an ephemeral
> znode 'registering' as a RegionServer. The source cluster then streams
> WALEdits to the Admin Protos method:
> {code}
> public ReplicateWALEntryResponse replicateWALEntry(final RpcController
> controller,
> final ReplicateWALEntryRequest request) throws ServiceException {
> {code}
> The hbase-indexer relies on other hbase internals like Server so it can get a
> ZooKeeperWatcher instance and know the 'name' to use for this cut-down server.
> Thoughts on how to proceed include:
>
> * Better formalize its current digestion of hbase internals; make it so
> rpcserver is allowed to be used by others, etc. This would be hard to do
> given they use basics like Server, Protobuf serdes for WAL types, and
> AdminProtos Service. Any change in this wide API breaks (again)
> hbase-indexer. We have made a 'channel' for Coprocessor Endpoints so they
> continue to work though they use 'internal' types. They can use protos in
> hbase-protocol. hbase-protocol protos are in a limbo currently where they are
> sort-of 'public'; a TODO. Perhaps the hbase-indexer could do similar relying
> on the hbase-protocol (pb2.5) content and we could do something to reveal
> rpcserver and zk for hbase-indexer safe use.
> * Start an actual RegionServer only have it register the AdminProtos Service
> only -- not ClientProtos and the Service that does Master interaction, etc.
> [I checked, this is not as easy to do as I at first thought -- St.Ack] Then
> have the hbase-indexer implement an AdminCoprocessor to override the
> replicateWALEntry method (the Admin CP implementation may need work). This
> would narrow the hbase-indexer exposure to that of the Admin Coprocessor
> Interface
> * Over in HBASE-10504, [~enis] suggested "... if we want to provide
> isolation for the replication services in hbase, we can have a simple host as
> another daemon which hosts the ReplicationEndpoint implementation. RS's will
> use a built-in RE to send the edits to this layer, and the host will delegate
> it to the RE implementation. The flow would be something like: RS --> RE
> inside RS --> Host daemon for RE --> Actual RE implementation --> third party
> system..."
>
> Other crazy notions occur including the setup of an Admin Interface
> Coprocessor Endpoint. A new ReplicationEndpoint would feed the replication
> stream to the remote cluster via the CPEP registered channel.
> But time is short. Hopefully we can figure something that will work in 2.0
> timeframe w/o too much code movement.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18922) Fix all dead links in our HBase book
[
https://issues.apache.org/jira/browse/HBASE-18922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214078#comment-16214078
]
Chia-Ping Tsai commented on HBASE-18922:
{code}
+As the HBase client communicates directly with the RegionServers, this can be
obtained via
link:https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/RegionLocator.html#getRegionLocation-byte:A-)[RegionLocator.getRegionLocation].
{code}
remove the ")". It breaks the navigation.
> Fix all dead links in our HBase book
>
>
> Key: HBASE-18922
> URL: https://issues.apache.org/jira/browse/HBASE-18922
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Chia-Ping Tsai
>Assignee: Yung-An He
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-18922-master.patch
>
>
> see
> [here|https://paper.dropbox.com/doc/dead-links-in-HBase-book-8YcTcH5mxZKn9TYlKJJq4?_tk=share_copylink]
> to find the dead links.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19051) Add new split algorithm for num string
[
https://issues.apache.org/jira/browse/HBASE-19051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214064#comment-16214064
]
Hudson commented on HBASE-19051:
FAILURE: Integrated in Jenkins build HBase-1.4 #963 (See
[https://builds.apache.org/job/HBase-1.4/963/])
HBASE-19051 Add new split algorithm for num string (tedyu: rev
06c243c48d4b280dd4a2e65b29f05773d9ca006f)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/util/RegionSplitter.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestRegionSplitter.java
> Add new split algorithm for num string
> --
>
> Key: HBASE-19051
> URL: https://issues.apache.org/jira/browse/HBASE-19051
> Project: HBase
> Issue Type: Improvement
>Reporter: Yun Zhao
>Assignee: Yun Zhao
>Priority: Minor
> Fix For: 1.4.0, 1.5.0, 2.0.0-alpha-4
>
> Attachments: HBASE-19051.branch-1.001.patch,
> HBASE-19051.master.001.patch, HBASE-19051.master.002.patch
>
>
> We will use the reversed sequential number or phone number as the first part
> of rowkey, there is no split algorithm to create a pre-split table, only by
> specify the split points.
> {code}
> create 't1','f', SPLITS => ['1','2','3','4','5','6','7','8','9']
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214057#comment-16214057
]
Hadoop QA commented on HBASE-18824:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 19m
55s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
16s{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} mvneclipse {color} | {color:green} 0m
12s{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} findbugs {color} | {color:green} 0m
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
59s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
36m 38s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
1s{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} 74m 46s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:cb5c477 |
| JIRA Issue | HBASE-18824 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893425/HBASE-18824.master.005.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 8c4cf9e40fbc 3.13.0-116-generic #163-Ubuntu SMP Fri Mar 31
14:13:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 592d541 |
| Default Java | 1.8.0_141 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9308/testReport/ |
| modules | C: hbase-common U: hbase-common |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9308/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
[jira] [Commented] (HBASE-19051) Add new split algorithm for num string
[
https://issues.apache.org/jira/browse/HBASE-19051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214055#comment-16214055
]
Hudson commented on HBASE-19051:
FAILURE: Integrated in Jenkins build HBase-1.5 #107 (See
[https://builds.apache.org/job/HBase-1.5/107/])
HBASE-19051 Add new split algorithm for num string (tedyu: rev
ae6a951658c2c12952c5f08d5cf3b021fd9a8d5f)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestRegionSplitter.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/util/RegionSplitter.java
> Add new split algorithm for num string
> --
>
> Key: HBASE-19051
> URL: https://issues.apache.org/jira/browse/HBASE-19051
> Project: HBase
> Issue Type: Improvement
>Reporter: Yun Zhao
>Assignee: Yun Zhao
>Priority: Minor
> Fix For: 1.4.0, 1.5.0, 2.0.0-alpha-4
>
> Attachments: HBASE-19051.branch-1.001.patch,
> HBASE-19051.master.001.patch, HBASE-19051.master.002.patch
>
>
> We will use the reversed sequential number or phone number as the first part
> of rowkey, there is no split algorithm to create a pre-split table, only by
> specify the split points.
> {code}
> create 't1','f', SPLITS => ['1','2','3','4','5','6','7','8','9']
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19007: -- Resolution: Fixed Status: Resolved (was: Patch Available) Pushed to master and branch-2. Thanks for all the helpful input and reviews. This approach much better than direction I was headed previous. > Align Services Interfaces in Master and RegionServer > > > Key: HBASE-19007 > URL: https://issues.apache.org/jira/browse/HBASE-19007 > Project: HBase > Issue Type: Task >Reporter: stack >Assignee: stack >Priority: Blocker > Labels: coprocessor > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19007.master.001.patch, > HBASE-19007.master.002.patch, HBASE-19007.master.003.patch, > HBASE-19007.master.004.patch, HBASE-19007.master.005.patch, > HBASE-19007.master.006.patch, HBASE-19007.master.007.patch, > HBASE-19007.master.008.patch, HBASE-19007.master.009.patch, > HBASE-19007.master.009.patch, HBASE-19007.master.010.patch, > HBASE-19007.master.011.patch, HBASE-19007.master.012.patch, > HBASE-19007.master.013.patch > > > HBASE-18183 adds a CoprocessorRegionServerService to give a view on > RegionServiceServices that is safe to expose to Coprocessors. > On the Master-side, MasterServices becomes an Interface for exposing to > Coprocessors. > We need to align the two. > For background, see > https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19010) Reimplement getMasterInfoPort for Admin
[
https://issues.apache.org/jira/browse/HBASE-19010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214043#comment-16214043
]
Hudson commented on HBASE-19010:
FAILURE: Integrated in Jenkins build HBase-2.0 #725 (See
[https://builds.apache.org/job/HBase-2.0/725/])
HBASE-19010 Reimplement getMasterInfoPort for Admin (zghao: rev
51ceeece257e944e71f5e159ab628f4ae632beb5)
* (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/ClusterStatus.java
* (edit) hbase-protocol-shaded/src/main/protobuf/ClusterStatus.proto
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncAdmin.java
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncClusterAdminApi.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientClusterStatus.java
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/shaded/protobuf/ProtobufUtil.java
* (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
* (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Admin.java
* (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/TestInfoServers.java
> Reimplement getMasterInfoPort for Admin
> ---
>
> Key: HBASE-19010
> URL: https://issues.apache.org/jira/browse/HBASE-19010
> Project: HBase
> Issue Type: Sub-task
> Components: Client
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19010.master.001.patch,
> HBASE-19010.master.002.patch, HBASE-19010.master.002.patch,
> HBASE-19010.master.002.patch, HBASE-19010.master.002.patch,
> HBASE-19010.master.003.patch, HBASE-19010.master.003.patch,
> HBASE-19010.master.004.patch, HBASE-19010.master.004.patch
>
>
> Current implementation.
> {code}
> public int getMasterInfoPort() throws IOException {
> // TODO: Fix! Reaching into internal implementation
> ConnectionImplementation connection =
> (ConnectionImplementation)this.connection;
> ZooKeeperKeepAliveConnection zkw =
> connection.getKeepAliveZooKeeperWatcher();
> try {
> return MasterAddressTracker.getMasterInfoPort(zkw);
> } catch (KeeperException e) {
> throw new IOException("Failed to get master info port from
> MasterAddressTracker", e);
> }
> }
> {code}
> Open this issue to fix TODO.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18922) Fix all dead links in our HBase book
[
https://issues.apache.org/jira/browse/HBASE-18922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214042#comment-16214042
]
Hadoop QA commented on HBASE-18922:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 13m
40s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
56s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
35s{color} | {color:green} master passed {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} mvneclipse {color} | {color:green} 1m
57s{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} javadoc {color} | {color:green} 2m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}143m
56s{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
22s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}174m 38s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:cb5c477 |
| JIRA Issue | HBASE-18922 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893408/HBASE-18922-master.patch
|
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux c95dc5a2a2a9 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 592d541 |
| Default Java | 1.8.0_141 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9304/testReport/ |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9304/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Fix all dead links in our HBase book
>
>
> Key: HBASE-18922
> URL: https://issues.apache.org/jira/browse/HBASE-18922
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Chia-Ping Tsai
>Assignee: Yung-An He
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-18922-master.patch
>
>
> see
> [here|https://paper.dropbox.com/doc/dead-links-in-HBase-book-8YcTcH5mxZKn9TYlKJJq4?_tk=share_copylink]
> to find the dead links.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Work started] (HBASE-18276) Release 1.2.7
[ https://issues.apache.org/jira/browse/HBASE-18276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-18276 started by Sean Busbey. --- > Release 1.2.7 > - > > Key: HBASE-18276 > URL: https://issues.apache.org/jira/browse/HBASE-18276 > Project: HBase > Issue Type: Task > Components: community >Reporter: Sean Busbey >Assignee: Sean Busbey > Fix For: 1.2.7 > > > about time to get rolling on 1.2.7 for ~monthly -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214041#comment-16214041
]
Chia-Ping Tsai commented on HBASE-18824:
LGTM, Nice comment!
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch,
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch,
> HBASE-18824.master.005.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiang Li updated HBASE-18824:
-
Attachment: HBASE-18824.master.005.patch
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch,
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch,
> HBASE-18824.master.005.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214032#comment-16214032
]
Xiang Li edited comment on HBASE-18824 at 10/21/17 5:16 PM:
Hi [~chia7712], thanks for your comment and patience!
1. Regarding
bq. The exeption is caused by that the number of cells we get is greater than
the max version we set to Get. That is unrelated to the Delete cells.
Yes, it is. But the max version we set to Get is the count of Delete cell,
which is recorded in a TreeMap called kvCount, mapping from qualifier to the
count of cell of that qualifier.
2. Regarding
bq. The count of cells we get for the Delete may be not equal with the count of
existing cells. The comment may mislead us about the data model of HBase. For
example, 4 Put cells exist in server, and then a Delete having 3 Delete cells
is submitted to server. The count of existing cells is 4, so the Delete
operation will fail?
Yes, it is not accurate to use the statement of "existing cell".
Patch 005 is uploaded to remove the usage of "existing cell". Thanks for the
suggestions!
was (Author: water):
Hi [~chia7712], thanks for your comment and patience!
1. Regarding
bq. The exeption is caused by that the number of cells we get is greater than
the max version we set to Get. That is unrelated to the Delete cells.
Yes, it is. But the max version we set to Get is the count of Delete cell,
which is recorded in a TreeMap called kvCount, mapping from qualifier to the
count of cell of that qualifier.
2. Regarding
bq. The count of cells we get for the Delete may be not equal with the count of
existing cells. The comment may mislead us about the data model of HBase. For
example, 4 Put cells exist in server, and then a Delete having 3 Delete cells
is submitted to server. The count of existing cells is 4, so the Delete
operation will fail?
Yes, it is not accurate to use the statement of "existing cell".
Patch 004 is uploaded to remove the usage of "existing cell". Thanks for the
suggestions!
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch,
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiang Li updated HBASE-18824:
-
Attachment: HBASE-18824.master.004.patch
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch,
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiang Li updated HBASE-18824:
-
Attachment: (was: HBASE-18824.master.004.patch)
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch,
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214032#comment-16214032
]
Xiang Li commented on HBASE-18824:
--
Hi [~chia7712], thanks for your comment and patience!
1. Regarding
bq. The exeption is caused by that the number of cells we get is greater than
the max version we set to Get. That is unrelated to the Delete cells.
Yes, it is. But the max version we set to Get is the count of Delete cell,
which is recorded in a TreeMap called kvCount, mapping from qualifier to the
count of cell of that qualifier.
2. Regarding
bq. The count of cells we get for the Delete may be not equal with the count of
existing cells. The comment may mislead us about the data model of HBase. For
example, 4 Put cells exist in server, and then a Delete having 3 Delete cells
is submitted to server. The count of existing cells is 4, so the Delete
operation will fail?
Yes, it is not accurate to use the statement of "existing cell".
Patch 004 is uploaded to remove the usage of "existing cell". Thanks for the
suggestions!
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch,
> HBASE-18824.master.003.patch, HBASE-18824.master.004.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19019) QA fails on hbase-thrift module with timeout
[
https://issues.apache.org/jira/browse/HBASE-19019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214025#comment-16214025
]
Chia-Ping Tsai commented on HBASE-19019:
IIRC, the 1.2, 1.3, 1.4, and branch-1 encounter the same timeout trouble...
> QA fails on hbase-thrift module with timeout
>
>
> Key: HBASE-19019
> URL: https://issues.apache.org/jira/browse/HBASE-19019
> Project: HBase
> Issue Type: Bug
> Components: Thrift
>Reporter: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-19019.branch-1.001.patch,
> HBASE-19019.branch-1.002.patch, HBASE-19019.branch-1.2.dummy.patch,
> HBASE-19019.master.001.patch
>
>
> For any modification in hbase-thrift module the precommit build fails with
> timeout for {{TestThriftServerCmdLine}}. I noticed this failure on multiple
> patches: HBASE-18967 and HBASE-18996 even when the patch did not contain any
> modification
> (https://issues.apache.org/jira/secure/attachment/12892414/HBASE-18967.branch-1.3.002.patch)
> The {{TestThriftServerCmdLine}} test passes locally on both mentioned patches.
> One failure: https://builds.apache.org/job/PreCommit-HBASE-Build/9127/
> {code}
> [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ hbase-thrift ---
> [INFO] Surefire report directory:
> /testptch/hbase/hbase-thrift/target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junitcore.JUnitCoreProvider
> [INFO] parallel='none', perCoreThreadCount=true, threadCount=0,
> useUnlimitedThreads=false, threadCountSuites=0, threadCountClasses=0,
> threadCountMethods=0, parallelOptimized=true
> ---
> T E S T S
> ---
> Running org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler
> Tests run: 29, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 48.201 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler
> Running
> org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithReadOnly
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.257 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithReadOnly
> Running
> org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithLabels
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.621 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithLabels
> Running org.apache.hadoop.hbase.thrift.TestCallQueue
> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.473 sec -
> in org.apache.hadoop.hbase.thrift.TestCallQueue
> Running org.apache.hadoop.hbase.thrift.TestThriftHttpServer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.239 sec -
> in org.apache.hadoop.hbase.thrift.TestThriftHttpServer
> Running org.apache.hadoop.hbase.thrift.TestThriftServer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 75.55 sec -
> in org.apache.hadoop.hbase.thrift.TestThriftServer
> Running org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine
> Results :
> Tests run: 72, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18:33.104s
> [INFO] Finished at: Mon Oct 16 03:42:59 UTC 2017
> [INFO] Final Memory: 61M/1299M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on
> project hbase-thrift: There was a timeout or other error in the fork -> [Help
> 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19019) QA fails on hbase-thrift module with timeout
[
https://issues.apache.org/jira/browse/HBASE-19019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19019:
---
Status: Patch Available (was: Open)
> QA fails on hbase-thrift module with timeout
>
>
> Key: HBASE-19019
> URL: https://issues.apache.org/jira/browse/HBASE-19019
> Project: HBase
> Issue Type: Bug
> Components: Thrift
>Reporter: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-19019.branch-1.001.patch,
> HBASE-19019.branch-1.002.patch, HBASE-19019.branch-1.2.dummy.patch,
> HBASE-19019.master.001.patch
>
>
> For any modification in hbase-thrift module the precommit build fails with
> timeout for {{TestThriftServerCmdLine}}. I noticed this failure on multiple
> patches: HBASE-18967 and HBASE-18996 even when the patch did not contain any
> modification
> (https://issues.apache.org/jira/secure/attachment/12892414/HBASE-18967.branch-1.3.002.patch)
> The {{TestThriftServerCmdLine}} test passes locally on both mentioned patches.
> One failure: https://builds.apache.org/job/PreCommit-HBASE-Build/9127/
> {code}
> [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ hbase-thrift ---
> [INFO] Surefire report directory:
> /testptch/hbase/hbase-thrift/target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junitcore.JUnitCoreProvider
> [INFO] parallel='none', perCoreThreadCount=true, threadCount=0,
> useUnlimitedThreads=false, threadCountSuites=0, threadCountClasses=0,
> threadCountMethods=0, parallelOptimized=true
> ---
> T E S T S
> ---
> Running org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler
> Tests run: 29, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 48.201 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler
> Running
> org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithReadOnly
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.257 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithReadOnly
> Running
> org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithLabels
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.621 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithLabels
> Running org.apache.hadoop.hbase.thrift.TestCallQueue
> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.473 sec -
> in org.apache.hadoop.hbase.thrift.TestCallQueue
> Running org.apache.hadoop.hbase.thrift.TestThriftHttpServer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.239 sec -
> in org.apache.hadoop.hbase.thrift.TestThriftHttpServer
> Running org.apache.hadoop.hbase.thrift.TestThriftServer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 75.55 sec -
> in org.apache.hadoop.hbase.thrift.TestThriftServer
> Running org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine
> Results :
> Tests run: 72, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18:33.104s
> [INFO] Finished at: Mon Oct 16 03:42:59 UTC 2017
> [INFO] Final Memory: 61M/1299M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on
> project hbase-thrift: There was a timeout or other error in the fork -> [Help
> 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19019) QA fails on hbase-thrift module with timeout
[
https://issues.apache.org/jira/browse/HBASE-19019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19019:
---
Attachment: HBASE-19019.branch-1.2.dummy.patch
trigger QA for branch-1.2
> QA fails on hbase-thrift module with timeout
>
>
> Key: HBASE-19019
> URL: https://issues.apache.org/jira/browse/HBASE-19019
> Project: HBase
> Issue Type: Bug
> Components: Thrift
>Reporter: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-19019.branch-1.001.patch,
> HBASE-19019.branch-1.002.patch, HBASE-19019.branch-1.2.dummy.patch,
> HBASE-19019.master.001.patch
>
>
> For any modification in hbase-thrift module the precommit build fails with
> timeout for {{TestThriftServerCmdLine}}. I noticed this failure on multiple
> patches: HBASE-18967 and HBASE-18996 even when the patch did not contain any
> modification
> (https://issues.apache.org/jira/secure/attachment/12892414/HBASE-18967.branch-1.3.002.patch)
> The {{TestThriftServerCmdLine}} test passes locally on both mentioned patches.
> One failure: https://builds.apache.org/job/PreCommit-HBASE-Build/9127/
> {code}
> [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ hbase-thrift ---
> [INFO] Surefire report directory:
> /testptch/hbase/hbase-thrift/target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junitcore.JUnitCoreProvider
> [INFO] parallel='none', perCoreThreadCount=true, threadCount=0,
> useUnlimitedThreads=false, threadCountSuites=0, threadCountClasses=0,
> threadCountMethods=0, parallelOptimized=true
> ---
> T E S T S
> ---
> Running org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler
> Tests run: 29, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 48.201 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler
> Running
> org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithReadOnly
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.257 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithReadOnly
> Running
> org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithLabels
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.621 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithLabels
> Running org.apache.hadoop.hbase.thrift.TestCallQueue
> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.473 sec -
> in org.apache.hadoop.hbase.thrift.TestCallQueue
> Running org.apache.hadoop.hbase.thrift.TestThriftHttpServer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.239 sec -
> in org.apache.hadoop.hbase.thrift.TestThriftHttpServer
> Running org.apache.hadoop.hbase.thrift.TestThriftServer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 75.55 sec -
> in org.apache.hadoop.hbase.thrift.TestThriftServer
> Running org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine
> Results :
> Tests run: 72, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18:33.104s
> [INFO] Finished at: Mon Oct 16 03:42:59 UTC 2017
> [INFO] Final Memory: 61M/1299M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on
> project hbase-thrift: There was a timeout or other error in the fork -> [Help
> 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19019) QA fails on hbase-thrift module with timeout
[
https://issues.apache.org/jira/browse/HBASE-19019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19019:
---
Status: Open (was: Patch Available)
> QA fails on hbase-thrift module with timeout
>
>
> Key: HBASE-19019
> URL: https://issues.apache.org/jira/browse/HBASE-19019
> Project: HBase
> Issue Type: Bug
> Components: Thrift
>Reporter: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-19019.branch-1.001.patch,
> HBASE-19019.branch-1.002.patch, HBASE-19019.master.001.patch
>
>
> For any modification in hbase-thrift module the precommit build fails with
> timeout for {{TestThriftServerCmdLine}}. I noticed this failure on multiple
> patches: HBASE-18967 and HBASE-18996 even when the patch did not contain any
> modification
> (https://issues.apache.org/jira/secure/attachment/12892414/HBASE-18967.branch-1.3.002.patch)
> The {{TestThriftServerCmdLine}} test passes locally on both mentioned patches.
> One failure: https://builds.apache.org/job/PreCommit-HBASE-Build/9127/
> {code}
> [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ hbase-thrift ---
> [INFO] Surefire report directory:
> /testptch/hbase/hbase-thrift/target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junitcore.JUnitCoreProvider
> [INFO] parallel='none', perCoreThreadCount=true, threadCount=0,
> useUnlimitedThreads=false, threadCountSuites=0, threadCountClasses=0,
> threadCountMethods=0, parallelOptimized=true
> ---
> T E S T S
> ---
> Running org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler
> Tests run: 29, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 48.201 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler
> Running
> org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithReadOnly
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.257 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithReadOnly
> Running
> org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithLabels
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.621 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithLabels
> Running org.apache.hadoop.hbase.thrift.TestCallQueue
> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.473 sec -
> in org.apache.hadoop.hbase.thrift.TestCallQueue
> Running org.apache.hadoop.hbase.thrift.TestThriftHttpServer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.239 sec -
> in org.apache.hadoop.hbase.thrift.TestThriftHttpServer
> Running org.apache.hadoop.hbase.thrift.TestThriftServer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 75.55 sec -
> in org.apache.hadoop.hbase.thrift.TestThriftServer
> Running org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine
> Results :
> Tests run: 72, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18:33.104s
> [INFO] Finished at: Mon Oct 16 03:42:59 UTC 2017
> [INFO] Final Memory: 61M/1299M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on
> project hbase-thrift: There was a timeout or other error in the fork -> [Help
> 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18645) Loads of tests timing out....
[
https://issues.apache.org/jira/browse/HBASE-18645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214021#comment-16214021
]
Hadoop QA commented on HBASE-18645:
---
| (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-18645 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-18645 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12883043/HBASE-18645.master.001.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9306/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Loads of tests timing out
> -
>
> Key: HBASE-18645
> URL: https://issues.apache.org/jira/browse/HBASE-18645
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Priority: Critical
> Attachments: HBASE-18645.master.001.patch,
> HBASE-18645.master.001.patch
>
>
> Whats up? Why are tests mostly timing out? When did it start? I can't seem to
> make it happen locally so tough doing a bisect.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19019) QA fails on hbase-thrift module with timeout
[
https://issues.apache.org/jira/browse/HBASE-19019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16214014#comment-16214014
]
Hadoop QA commented on HBASE-19019:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 14m
54s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
55s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
23s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
23s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
3s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
11s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
40s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
22s{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} mvneclipse {color} | {color:green} 0m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
22s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
25m 23s{color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3.
{color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
29s{color} | {color:green} hbase-thrift 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} 56m 25s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:4bf71c3 |
| JIRA Issue | HBASE-19019 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893418/HBASE-19019.branch-1.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 5b563b31831c 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | branch-1 / ae6a951 |
| Default Java | 1.7.0_151 |
| findbugs | v3.0.0 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9305/testReport/ |
| modules | C: hbase-thrift U: hbase-thrift |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9305/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> QA fails on hbase-thrift module with timeout
>
[jira] [Commented] (HBASE-19057) Merge branch HBASE-18410 to master branch
[ https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213998#comment-16213998 ] Anoop Sam John commented on HBASE-19057: bq.Actually, we have some type of filter , such as PrefixFilter, they have some state in their filterRowKey implementation, so if we return early, those filters will not have a chance to update they state, which lead to the failure result. UT indicate that. Can u say which exact UT fails.. IMO this says some thing wrong with the impl of such filters. Will see the test case and study code to see why this short circuit will have impact. > Merge branch HBASE-18410 to master branch > - > > Key: HBASE-19057 > URL: https://issues.apache.org/jira/browse/HBASE-19057 > Project: HBase > Issue Type: Sub-task > Components: Filters >Reporter: Zheng Hu >Assignee: Zheng Hu > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19057-HBASE-18410.v1.patch > > > Open this issue to fix conflict , run HadoopQA and gather other feedback. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19010) Reimplement getMasterInfoPort for Admin
[
https://issues.apache.org/jira/browse/HBASE-19010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213991#comment-16213991
]
Hudson commented on HBASE-19010:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3925 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/3925/])
HBASE-19010 Reimplement getMasterInfoPort for Admin (zghao: rev
592d541f5d5e5fea5668915e0400f048fa3f65e3)
* (edit) hbase-protocol-shaded/src/main/protobuf/ClusterStatus.proto
* (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Admin.java
* (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/TestInfoServers.java
* (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
* (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/ClusterStatus.java
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncAdmin.java
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/shaded/protobuf/ProtobufUtil.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncClusterAdminApi.java
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientClusterStatus.java
> Reimplement getMasterInfoPort for Admin
> ---
>
> Key: HBASE-19010
> URL: https://issues.apache.org/jira/browse/HBASE-19010
> Project: HBase
> Issue Type: Sub-task
> Components: Client
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19010.master.001.patch,
> HBASE-19010.master.002.patch, HBASE-19010.master.002.patch,
> HBASE-19010.master.002.patch, HBASE-19010.master.002.patch,
> HBASE-19010.master.003.patch, HBASE-19010.master.003.patch,
> HBASE-19010.master.004.patch, HBASE-19010.master.004.patch
>
>
> Current implementation.
> {code}
> public int getMasterInfoPort() throws IOException {
> // TODO: Fix! Reaching into internal implementation
> ConnectionImplementation connection =
> (ConnectionImplementation)this.connection;
> ZooKeeperKeepAliveConnection zkw =
> connection.getKeepAliveZooKeeperWatcher();
> try {
> return MasterAddressTracker.getMasterInfoPort(zkw);
> } catch (KeeperException e) {
> throw new IOException("Failed to get master info port from
> MasterAddressTracker", e);
> }
> }
> {code}
> Open this issue to fix TODO.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19057) Merge branch HBASE-18410 to master branch
[ https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-19057: - Attachment: HBASE-19057-HBASE-18410.v1.patch > Merge branch HBASE-18410 to master branch > - > > Key: HBASE-19057 > URL: https://issues.apache.org/jira/browse/HBASE-19057 > Project: HBase > Issue Type: Sub-task > Components: Filters >Reporter: Zheng Hu >Assignee: Zheng Hu > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19057-HBASE-18410.v1.patch > > > Open this issue to fix conflict , run HadoopQA and gather other feedback. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19057) Merge branch HBASE-18410 to master branch
[ https://issues.apache.org/jira/browse/HBASE-19057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213979#comment-16213979 ] Zheng Hu commented on HBASE-19057: -- [~anoop.hbase], Thanks for your reply. Agree your first 4 points. point #2 is my mistake. Thanks for the careful review. point #4 is a nice optimization , *_NEXT_COL and *_NEXT_ROW are the same case, I think. Some discussion about the last 2 points: point #5 > I dont think in any of the FL filterRowKey, we should call filterAllRemaining. Sounds good, the filterRowKey of FilterList is false , it indicate that they exist at least one sub-filter whose filterRowKey is false, However for those sub-filters whose filterAllRemaining are true, their filterRowKey are definitely true. So filterAllRemaining can be removed. > Also can early out than just set retVal and continue, as in AND filter Actually, we have some type of filter , such as PrefixFilter, they have some state in their filterRowKey implementation, so if we return early, those filters will not have a chance to update they state, which lead to the failure result. UT indicate that. point #6 > Got now why no seekHintFilter set here. As that has to be all filters. Yes, only when all filters return seek_hint, our FL return seek_hint. > But other things abt filterAllRemaining is still valid Sounds good. > Merge branch HBASE-18410 to master branch > - > > Key: HBASE-19057 > URL: https://issues.apache.org/jira/browse/HBASE-19057 > Project: HBase > Issue Type: Sub-task > Components: Filters >Reporter: Zheng Hu >Assignee: Zheng Hu > Fix For: 2.0.0-beta-1 > > > Open this issue to fix conflict , run HadoopQA and gather other feedback. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19019) QA fails on hbase-thrift module with timeout
[
https://issues.apache.org/jira/browse/HBASE-19019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213963#comment-16213963
]
Peter Somogyi commented on HBASE-19019:
---
Attached branch-1 patch ignoring TestThriftServerCmdLine.
> QA fails on hbase-thrift module with timeout
>
>
> Key: HBASE-19019
> URL: https://issues.apache.org/jira/browse/HBASE-19019
> Project: HBase
> Issue Type: Bug
> Components: Thrift
>Reporter: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-19019.branch-1.001.patch,
> HBASE-19019.branch-1.002.patch, HBASE-19019.master.001.patch
>
>
> For any modification in hbase-thrift module the precommit build fails with
> timeout for {{TestThriftServerCmdLine}}. I noticed this failure on multiple
> patches: HBASE-18967 and HBASE-18996 even when the patch did not contain any
> modification
> (https://issues.apache.org/jira/secure/attachment/12892414/HBASE-18967.branch-1.3.002.patch)
> The {{TestThriftServerCmdLine}} test passes locally on both mentioned patches.
> One failure: https://builds.apache.org/job/PreCommit-HBASE-Build/9127/
> {code}
> [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ hbase-thrift ---
> [INFO] Surefire report directory:
> /testptch/hbase/hbase-thrift/target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junitcore.JUnitCoreProvider
> [INFO] parallel='none', perCoreThreadCount=true, threadCount=0,
> useUnlimitedThreads=false, threadCountSuites=0, threadCountClasses=0,
> threadCountMethods=0, parallelOptimized=true
> ---
> T E S T S
> ---
> Running org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler
> Tests run: 29, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 48.201 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler
> Running
> org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithReadOnly
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.257 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithReadOnly
> Running
> org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithLabels
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.621 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithLabels
> Running org.apache.hadoop.hbase.thrift.TestCallQueue
> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.473 sec -
> in org.apache.hadoop.hbase.thrift.TestCallQueue
> Running org.apache.hadoop.hbase.thrift.TestThriftHttpServer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.239 sec -
> in org.apache.hadoop.hbase.thrift.TestThriftHttpServer
> Running org.apache.hadoop.hbase.thrift.TestThriftServer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 75.55 sec -
> in org.apache.hadoop.hbase.thrift.TestThriftServer
> Running org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine
> Results :
> Tests run: 72, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18:33.104s
> [INFO] Finished at: Mon Oct 16 03:42:59 UTC 2017
> [INFO] Final Memory: 61M/1299M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on
> project hbase-thrift: There was a timeout or other error in the fork -> [Help
> 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19051) Add new split algorithm for num string
[
https://issues.apache.org/jira/browse/HBASE-19051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-19051:
---
Fix Version/s: 1.5.0
1.4.0
> Add new split algorithm for num string
> --
>
> Key: HBASE-19051
> URL: https://issues.apache.org/jira/browse/HBASE-19051
> Project: HBase
> Issue Type: Improvement
>Reporter: Yun Zhao
>Assignee: Yun Zhao
>Priority: Minor
> Fix For: 1.4.0, 1.5.0, 2.0.0-alpha-4
>
> Attachments: HBASE-19051.branch-1.001.patch,
> HBASE-19051.master.001.patch, HBASE-19051.master.002.patch
>
>
> We will use the reversed sequential number or phone number as the first part
> of rowkey, there is no split algorithm to create a pre-split table, only by
> specify the split points.
> {code}
> create 't1','f', SPLITS => ['1','2','3','4','5','6','7','8','9']
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19019) QA fails on hbase-thrift module with timeout
[
https://issues.apache.org/jira/browse/HBASE-19019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi updated HBASE-19019:
--
Attachment: HBASE-19019.branch-1.002.patch
> QA fails on hbase-thrift module with timeout
>
>
> Key: HBASE-19019
> URL: https://issues.apache.org/jira/browse/HBASE-19019
> Project: HBase
> Issue Type: Bug
> Components: Thrift
>Reporter: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-19019.branch-1.001.patch,
> HBASE-19019.branch-1.002.patch, HBASE-19019.master.001.patch
>
>
> For any modification in hbase-thrift module the precommit build fails with
> timeout for {{TestThriftServerCmdLine}}. I noticed this failure on multiple
> patches: HBASE-18967 and HBASE-18996 even when the patch did not contain any
> modification
> (https://issues.apache.org/jira/secure/attachment/12892414/HBASE-18967.branch-1.3.002.patch)
> The {{TestThriftServerCmdLine}} test passes locally on both mentioned patches.
> One failure: https://builds.apache.org/job/PreCommit-HBASE-Build/9127/
> {code}
> [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ hbase-thrift ---
> [INFO] Surefire report directory:
> /testptch/hbase/hbase-thrift/target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junitcore.JUnitCoreProvider
> [INFO] parallel='none', perCoreThreadCount=true, threadCount=0,
> useUnlimitedThreads=false, threadCountSuites=0, threadCountClasses=0,
> threadCountMethods=0, parallelOptimized=true
> ---
> T E S T S
> ---
> Running org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler
> Tests run: 29, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 48.201 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler
> Running
> org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithReadOnly
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.257 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithReadOnly
> Running
> org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithLabels
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.621 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithLabels
> Running org.apache.hadoop.hbase.thrift.TestCallQueue
> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.473 sec -
> in org.apache.hadoop.hbase.thrift.TestCallQueue
> Running org.apache.hadoop.hbase.thrift.TestThriftHttpServer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.239 sec -
> in org.apache.hadoop.hbase.thrift.TestThriftHttpServer
> Running org.apache.hadoop.hbase.thrift.TestThriftServer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 75.55 sec -
> in org.apache.hadoop.hbase.thrift.TestThriftServer
> Running org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine
> Results :
> Tests run: 72, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18:33.104s
> [INFO] Finished at: Mon Oct 16 03:42:59 UTC 2017
> [INFO] Final Memory: 61M/1299M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on
> project hbase-thrift: There was a timeout or other error in the fork -> [Help
> 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19051) Add new split algorithm for num string
[
https://issues.apache.org/jira/browse/HBASE-19051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213960#comment-16213960
]
Ted Yu commented on HBASE-19051:
Test failures on QA run were not related:
https://builds.apache.org/job/PreCommit-HBASE-Build/9293/
> Add new split algorithm for num string
> --
>
> Key: HBASE-19051
> URL: https://issues.apache.org/jira/browse/HBASE-19051
> Project: HBase
> Issue Type: Improvement
>Reporter: Yun Zhao
>Assignee: Yun Zhao
>Priority: Minor
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19051.branch-1.001.patch,
> HBASE-19051.master.001.patch, HBASE-19051.master.002.patch
>
>
> We will use the reversed sequential number or phone number as the first part
> of rowkey, there is no split algorithm to create a pre-split table, only by
> specify the split points.
> {code}
> create 't1','f', SPLITS => ['1','2','3','4','5','6','7','8','9']
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19019) QA fails on hbase-thrift module with timeout
[
https://issues.apache.org/jira/browse/HBASE-19019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213957#comment-16213957
]
Chia-Ping Tsai commented on HBASE-19019:
It seems the TestThriftServerCmdLine hangs. Would you please submit a patch
ignoring the TestThriftServerCmdLine?
> QA fails on hbase-thrift module with timeout
>
>
> Key: HBASE-19019
> URL: https://issues.apache.org/jira/browse/HBASE-19019
> Project: HBase
> Issue Type: Bug
> Components: Thrift
>Reporter: Peter Somogyi
>Priority: Critical
> Attachments: HBASE-19019.branch-1.001.patch,
> HBASE-19019.master.001.patch
>
>
> For any modification in hbase-thrift module the precommit build fails with
> timeout for {{TestThriftServerCmdLine}}. I noticed this failure on multiple
> patches: HBASE-18967 and HBASE-18996 even when the patch did not contain any
> modification
> (https://issues.apache.org/jira/secure/attachment/12892414/HBASE-18967.branch-1.3.002.patch)
> The {{TestThriftServerCmdLine}} test passes locally on both mentioned patches.
> One failure: https://builds.apache.org/job/PreCommit-HBASE-Build/9127/
> {code}
> [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ hbase-thrift ---
> [INFO] Surefire report directory:
> /testptch/hbase/hbase-thrift/target/surefire-reports
> [INFO] Using configured provider
> org.apache.maven.surefire.junitcore.JUnitCoreProvider
> [INFO] parallel='none', perCoreThreadCount=true, threadCount=0,
> useUnlimitedThreads=false, threadCountSuites=0, threadCountClasses=0,
> threadCountMethods=0, parallelOptimized=true
> ---
> T E S T S
> ---
> Running org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler
> Tests run: 29, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 48.201 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandler
> Running
> org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithReadOnly
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.257 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithReadOnly
> Running
> org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithLabels
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.621 sec -
> in org.apache.hadoop.hbase.thrift2.TestThriftHBaseServiceHandlerWithLabels
> Running org.apache.hadoop.hbase.thrift.TestCallQueue
> Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.473 sec -
> in org.apache.hadoop.hbase.thrift.TestCallQueue
> Running org.apache.hadoop.hbase.thrift.TestThriftHttpServer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.239 sec -
> in org.apache.hadoop.hbase.thrift.TestThriftHttpServer
> Running org.apache.hadoop.hbase.thrift.TestThriftServer
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 75.55 sec -
> in org.apache.hadoop.hbase.thrift.TestThriftServer
> Running org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine
> Results :
> Tests run: 72, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 18:33.104s
> [INFO] Finished at: Mon Oct 16 03:42:59 UTC 2017
> [INFO] Final Memory: 61M/1299M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on
> project hbase-thrift: There was a timeout or other error in the fork -> [Help
> 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19052) FixedFileTrailer should recognize CellComparatorImpl class in branch-1.x
[
https://issues.apache.org/jira/browse/HBASE-19052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213954#comment-16213954
]
Ted Yu commented on HBASE-19052:
https://builds.apache.org/job/PreCommit-HBASE-Build/9299/console timed out.
Looking at :
https://builds.apache.org/job/PreCommit-HBASE-Build/9299/artifact/patchprocess/patch-unit-hbase-server.txt
there was no failed test.
Planning to commit on Monday if there is no further review comment.
> FixedFileTrailer should recognize CellComparatorImpl class in branch-1.x
>
>
> Key: HBASE-19052
> URL: https://issues.apache.org/jira/browse/HBASE-19052
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
> Attachments: 19052.branch-1.txt
>
>
> HBASE-18945 has gone into branch-2 .
> Let's consider rolling upgrade scenario from 1.x to 2.0 where there're three
> servers: s1, s2, s3
> s1 is upgraded to 2.0 first. It flushes to hfile in region r1 with
> CellComparatorImpl written in the hfile trailer.
> Somehow s1 crashes and master assigns r1 to s2 which is still running 1.x
> The following code in FixedFileTrailer would be triggered:
> {code}
> try {
> comparatorKlass = (Class)
> Class.forName(comparatorClassName);
> } catch (ClassNotFoundException e) {
> throw new IOException(e);
> }
> {code}
> since s2 is not aware of CellComparatorImpl.
> This issue is to backport CellComparatorImpl related change to branch-1.x
> Note: CellComparatorImpl wouldn't be used in write path, only in read path.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18922) Fix all dead links in our HBase book
[ https://issues.apache.org/jira/browse/HBASE-18922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yung-An He updated HBASE-18922: --- Status: Patch Available (was: Open) > Fix all dead links in our HBase book > > > Key: HBASE-18922 > URL: https://issues.apache.org/jira/browse/HBASE-18922 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Chia-Ping Tsai >Assignee: Yung-An He > Labels: beginner > Fix For: 2.0.0 > > Attachments: HBASE-18922-master.patch > > > see > [here|https://paper.dropbox.com/doc/dead-links-in-HBase-book-8YcTcH5mxZKn9TYlKJJq4?_tk=share_copylink] > to find the dead links. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Work stopped] (HBASE-18922) Fix all dead links in our HBase book
[ https://issues.apache.org/jira/browse/HBASE-18922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-18922 stopped by Yung-An He. -- > Fix all dead links in our HBase book > > > Key: HBASE-18922 > URL: https://issues.apache.org/jira/browse/HBASE-18922 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Chia-Ping Tsai >Assignee: Yung-An He > Labels: beginner > Fix For: 2.0.0 > > Attachments: HBASE-18922-master.patch > > > see > [here|https://paper.dropbox.com/doc/dead-links-in-HBase-book-8YcTcH5mxZKn9TYlKJJq4?_tk=share_copylink] > to find the dead links. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19019) QA fails on hbase-thrift module with timeout
[
https://issues.apache.org/jira/browse/HBASE-19019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213936#comment-16213936
]
Hadoop QA commented on HBASE-19019:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 14m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
0s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
22s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
25s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
6s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
14s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
39s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
30s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
28m 47s{color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3.
{color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
42s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}479m 41s{color}
| {color:red} hbase-thrift in the patch failed. {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}535m 37s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:4bf71c3 |
| JIRA Issue | HBASE-19019 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893397/HBASE-19019.branch-1.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 8fff290ae277 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | branch-1 / 4bf71c3 |
| Default Java | 1.7.0_151 |
| findbugs | v3.0.0 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/9301/artifact/patchprocess/patch-unit-hbase-thrift.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9301/testReport/ |
| modules | C: hbase-thrift U: hbase-thrift |
| Console
[jira] [Commented] (HBASE-19046) RegionObserver#postCompactSelection Passing an ImmutableList param of PB type
[ https://issues.apache.org/jira/browse/HBASE-19046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213852#comment-16213852 ] Chia-Ping Tsai commented on HBASE-19046: bq. compaction.getRequest().getFiles() returns Collection not List. So we can not directly use the above. Or else we have to pass Collection to CP hook not List.. That is why did not change here. What do u say? Got it. +1 > RegionObserver#postCompactSelection Passing an ImmutableList param of PB type > -- > > Key: HBASE-19046 > URL: https://issues.apache.org/jira/browse/HBASE-19046 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19046.patch > > > Dont think there is any specific need for passing this PB type. We can just > pass an unmodifiableList list object. Javadoc can say this is an > unmodifiableList . Thats it . No need that the type itself to be > Immutable... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[
https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213849#comment-16213849
]
Hadoop QA commented on HBASE-19007:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 15m
3s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 28 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
20s{color} | {color:blue} Maven dependency ordering for branch {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} 2m
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 8m
1s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 7m
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
0s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
10s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
45m 8s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 8m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
50s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}126m
38s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
14s{color} | {color:green} hbase-thrift in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
59s{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
33s{color} | {color:green} hbase-endpoint in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
7s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}246m 53s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:cb5c477 |
| JIRA Issue | HBASE-19007 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893401/HBASE-19007.master.013.patch
|
| Optional Tests |
[jira] [Updated] (HBASE-19010) Reimplement getMasterInfoPort for Admin
[
https://issues.apache.org/jira/browse/HBASE-19010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang updated HBASE-19010:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
Pushed to master and branch-2. Thanks all for reviewing.
> Reimplement getMasterInfoPort for Admin
> ---
>
> Key: HBASE-19010
> URL: https://issues.apache.org/jira/browse/HBASE-19010
> Project: HBase
> Issue Type: Sub-task
> Components: Client
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19010.master.001.patch,
> HBASE-19010.master.002.patch, HBASE-19010.master.002.patch,
> HBASE-19010.master.002.patch, HBASE-19010.master.002.patch,
> HBASE-19010.master.003.patch, HBASE-19010.master.003.patch,
> HBASE-19010.master.004.patch, HBASE-19010.master.004.patch
>
>
> Current implementation.
> {code}
> public int getMasterInfoPort() throws IOException {
> // TODO: Fix! Reaching into internal implementation
> ConnectionImplementation connection =
> (ConnectionImplementation)this.connection;
> ZooKeeperKeepAliveConnection zkw =
> connection.getKeepAliveZooKeeperWatcher();
> try {
> return MasterAddressTracker.getMasterInfoPort(zkw);
> } catch (KeeperException e) {
> throw new IOException("Failed to get master info port from
> MasterAddressTracker", e);
> }
> }
> {code}
> Open this issue to fix TODO.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19058) The wget isn't installed in building docker image
[
https://issues.apache.org/jira/browse/HBASE-19058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213837#comment-16213837
]
Hudson commented on HBASE-19058:
FAILURE: Integrated in Jenkins build HBase-2.0 #723 (See
[https://builds.apache.org/job/HBase-2.0/723/])
HBASE-19058. The wget isn't installed in building docker image (busbey: rev
d8afa3e067c50e47eeadb9ebfa6f209cd86bbb44)
* (edit) dev-support/docker/Dockerfile
> The wget isn't installed in building docker image
> -
>
> Key: HBASE-19058
> URL: https://issues.apache.org/jira/browse/HBASE-19058
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-19058.v0.patch, HBASE-19058.v0.tests.patch
>
>
> see
> [console|https://builds.apache.org/job/PreCommit-HBASE-Build/9259/consoleFull].
>
> {quote}
> 05:38:19 /testptch/patchprocess/precommit/personality/provided.sh: line 121:
> wget: command not found
> 05:38:19 Wget error 127 in fetching excludes file from url
> https://builds.apache.org/job/HBase-Find-Flaky-Tests/lastSuccessfulBuild/artifact/excludes/.
> Ignoring and proceeding.
> 05:38:22 cd /testptch/hbase/hbase-server
> {quote}
> We don't force docker to install {{wget}} before because {{wget}} is in the
> pre-depends of oracle-java8-installer.
> {code}
> $ sudo apt-rdepends oracle-java8-installer | grep "wget"
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> PreDepends: wget
> wget
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-16290) Dump summary of callQueue content; can help debugging
[ https://issues.apache.org/jira/browse/HBASE-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213826#comment-16213826 ] Sreeram Venkatasubramanian commented on HBASE-16290: [~chia7712]], I have uploaded the patch to the review board - [https://reviews.apache.org/r/63201/] > Dump summary of callQueue content; can help debugging > - > > Key: HBASE-16290 > URL: https://issues.apache.org/jira/browse/HBASE-16290 > Project: HBase > Issue Type: Bug > Components: Operability >Affects Versions: 2.0.0 >Reporter: stack >Assignee: Sreeram Venkatasubramanian > Labels: beginner > Fix For: 2.0.0 > > Attachments: DebugDump_screenshot.png, HBASE-16290.master.001.patch, > HBASE-16290.master.002.patch, HBASE-16290.master.003.patch, > HBASE-16290.master.004.patch, HBASE-16290.master.005.patch, > HBASE-16290.master.006.patch, Sample Summary.txt > > > Being able to get a clue what is in a backedup callQueue could give insight > on what is going on on a jacked server. Just needs to summarize count, sizes, > call types. Useful debugging. In a servlet? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-16290) Dump summary of callQueue content; can help debugging
[ https://issues.apache.org/jira/browse/HBASE-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213826#comment-16213826 ] Sreeram Venkatasubramanian edited comment on HBASE-16290 at 10/21/17 9:34 AM: -- [~chia7712], I have uploaded the patch to the review board - [https://reviews.apache.org/r/63201/] was (Author: sreeram): [~chia7712]], I have uploaded the patch to the review board - [https://reviews.apache.org/r/63201/] > Dump summary of callQueue content; can help debugging > - > > Key: HBASE-16290 > URL: https://issues.apache.org/jira/browse/HBASE-16290 > Project: HBase > Issue Type: Bug > Components: Operability >Affects Versions: 2.0.0 >Reporter: stack >Assignee: Sreeram Venkatasubramanian > Labels: beginner > Fix For: 2.0.0 > > Attachments: DebugDump_screenshot.png, HBASE-16290.master.001.patch, > HBASE-16290.master.002.patch, HBASE-16290.master.003.patch, > HBASE-16290.master.004.patch, HBASE-16290.master.005.patch, > HBASE-16290.master.006.patch, Sample Summary.txt > > > Being able to get a clue what is in a backedup callQueue could give insight > on what is going on on a jacked server. Just needs to summarize count, sizes, > call types. Useful debugging. In a servlet? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19058) The wget isn't installed in building docker image
[
https://issues.apache.org/jira/browse/HBASE-19058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213823#comment-16213823
]
Hudson commented on HBASE-19058:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3923 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/3923/])
HBASE-19058. The wget isn't installed in building docker image (busbey: rev
cb5c4776deee270ea21afc52d4ba70d9474d8a8a)
* (edit) dev-support/docker/Dockerfile
> The wget isn't installed in building docker image
> -
>
> Key: HBASE-19058
> URL: https://issues.apache.org/jira/browse/HBASE-19058
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-19058.v0.patch, HBASE-19058.v0.tests.patch
>
>
> see
> [console|https://builds.apache.org/job/PreCommit-HBASE-Build/9259/consoleFull].
>
> {quote}
> 05:38:19 /testptch/patchprocess/precommit/personality/provided.sh: line 121:
> wget: command not found
> 05:38:19 Wget error 127 in fetching excludes file from url
> https://builds.apache.org/job/HBase-Find-Flaky-Tests/lastSuccessfulBuild/artifact/excludes/.
> Ignoring and proceeding.
> 05:38:22 cd /testptch/hbase/hbase-server
> {quote}
> We don't force docker to install {{wget}} before because {{wget}} is in the
> pre-depends of oracle-java8-installer.
> {code}
> $ sudo apt-rdepends oracle-java8-installer | grep "wget"
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> PreDepends: wget
> wget
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18922) Fix all dead links in our HBase book
[ https://issues.apache.org/jira/browse/HBASE-18922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213816#comment-16213816 ] Yung-An He commented on HBASE-18922: Thank you again, [~chia7712]. Patch file has been uploaded. If there is any issue with the file, please let me know me know, thank you. > Fix all dead links in our HBase book > > > Key: HBASE-18922 > URL: https://issues.apache.org/jira/browse/HBASE-18922 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Chia-Ping Tsai >Assignee: Yung-An He > Labels: beginner > Fix For: 2.0.0 > > Attachments: HBASE-18922-master.patch > > > see > [here|https://paper.dropbox.com/doc/dead-links-in-HBase-book-8YcTcH5mxZKn9TYlKJJq4?_tk=share_copylink] > to find the dead links. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18922) Fix all dead links in our HBase book
[ https://issues.apache.org/jira/browse/HBASE-18922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yung-An He updated HBASE-18922: --- Attachment: HBASE-18922-master.patch Add patch file. > Fix all dead links in our HBase book > > > Key: HBASE-18922 > URL: https://issues.apache.org/jira/browse/HBASE-18922 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Chia-Ping Tsai >Assignee: Yung-An He > Labels: beginner > Fix For: 2.0.0 > > Attachments: HBASE-18922-master.patch > > > see > [here|https://paper.dropbox.com/doc/dead-links-in-HBase-book-8YcTcH5mxZKn9TYlKJJq4?_tk=share_copylink] > to find the dead links. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Work started] (HBASE-18922) Fix all dead links in our HBase book
[ https://issues.apache.org/jira/browse/HBASE-18922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-18922 started by Yung-An He. -- > Fix all dead links in our HBase book > > > Key: HBASE-18922 > URL: https://issues.apache.org/jira/browse/HBASE-18922 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Chia-Ping Tsai >Assignee: Yung-An He > Labels: beginner > Fix For: 2.0.0 > > > see > [here|https://paper.dropbox.com/doc/dead-links-in-HBase-book-8YcTcH5mxZKn9TYlKJJq4?_tk=share_copylink] > to find the dead links. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16290) Dump summary of callQueue content; can help debugging
[
https://issues.apache.org/jira/browse/HBASE-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213810#comment-16213810
]
Hadoop QA commented on HBASE-16290:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
10s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
14s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
11s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s{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} 3m
18s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
32m 51s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 89m
9s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
10s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}140m 19s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:cb5c477 |
| JIRA Issue | HBASE-16290 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893398/HBASE-16290.master.006.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 1132e01bf9d9 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / cb5c477 |
| Default Java | 1.8.0_141 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9302/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9302/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Dump summary of callQueue content; can help debugging
>
[jira] [Commented] (HBASE-19058) The wget isn't installed in building docker image
[
https://issues.apache.org/jira/browse/HBASE-19058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213809#comment-16213809
]
Hudson commented on HBASE-19058:
SUCCESS: Integrated in Jenkins build HBase-1.4 #962 (See
[https://builds.apache.org/job/HBase-1.4/962/])
HBASE-19058. The wget isn't installed in building docker image (busbey: rev
89abc298900aa36c889ec2c8145c0112a78ecd1f)
* (edit) dev-support/docker/Dockerfile
> The wget isn't installed in building docker image
> -
>
> Key: HBASE-19058
> URL: https://issues.apache.org/jira/browse/HBASE-19058
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-19058.v0.patch, HBASE-19058.v0.tests.patch
>
>
> see
> [console|https://builds.apache.org/job/PreCommit-HBASE-Build/9259/consoleFull].
>
> {quote}
> 05:38:19 /testptch/patchprocess/precommit/personality/provided.sh: line 121:
> wget: command not found
> 05:38:19 Wget error 127 in fetching excludes file from url
> https://builds.apache.org/job/HBase-Find-Flaky-Tests/lastSuccessfulBuild/artifact/excludes/.
> Ignoring and proceeding.
> 05:38:22 cd /testptch/hbase/hbase-server
> {quote}
> We don't force docker to install {{wget}} before because {{wget}} is in the
> pre-depends of oracle-java8-installer.
> {code}
> $ sudo apt-rdepends oracle-java8-installer | grep "wget"
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> PreDepends: wget
> wget
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19018) Use of hadoop internals that require bouncycastle should declare bouncycastle dependency
[
https://issues.apache.org/jira/browse/HBASE-19018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213808#comment-16213808
]
Hadoop QA commented on HBASE-19018:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
15s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
42s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 20m
41s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 5m
11s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
30s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 5m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
48s{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
4s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
10s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
44m 16s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
29s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}145m 38s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}234m 42s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:cb5c477 |
| JIRA Issue | HBASE-19018 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893052/HBASE-19018.0.patch |
| Optional Tests | asflicense javac javadoc unit shadedjars hadoopcheck
xml compile |
| uname | Linux 44e682e56481 3.13.0-117-generic #164-Ubuntu SMP Fri Apr 7
11:05:26 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / cb5c477 |
| Default Java | 1.8.0_141 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/9298/artifact/patchprocess/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9298/testReport/ |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9298/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Use of hadoop internals that require bouncycastle should declare bouncycastle
> dependency
>
>
>
[jira] [Commented] (HBASE-19049) Update kerby to 1.0.1 GA release
[
https://issues.apache.org/jira/browse/HBASE-19049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213806#comment-16213806
]
Hadoop QA commented on HBASE-19049:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
20s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 12m
56s{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
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
57s{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
2s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
53s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
37m 56s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
46s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}144m 59s{color}
| {color:red} root 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}210m 55s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:cb5c477 |
| JIRA Issue | HBASE-19049 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893285/HBASE-19049.1.patch |
| Optional Tests | asflicense javac javadoc unit shadedjars hadoopcheck
xml compile |
| uname | Linux ff342fb1819e 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / cb5c477 |
| Default Java | 1.8.0_141 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/9300/artifact/patchprocess/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9300/testReport/ |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9300/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Update kerby to 1.0.1 GA release
>
>
> Key: HBASE-19049
> URL: https://issues.apache.org/jira/browse/HBASE-19049
> Project: HBase
> Issue Type: Task
> Components: dependencies
>Affects Versions: 2.0.0-alpha-3
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-19049.0.patch, HBASE-19049.1.patch
[jira] [Commented] (HBASE-19058) The wget isn't installed in building docker image
[
https://issues.apache.org/jira/browse/HBASE-19058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213784#comment-16213784
]
Hudson commented on HBASE-19058:
FAILURE: Integrated in Jenkins build HBase-1.5 #106 (See
[https://builds.apache.org/job/HBase-1.5/106/])
HBASE-19058. The wget isn't installed in building docker image (busbey: rev
4bf71c3a1aaeb69da6a872189317a340462949c1)
* (edit) dev-support/docker/Dockerfile
> The wget isn't installed in building docker image
> -
>
> Key: HBASE-19058
> URL: https://issues.apache.org/jira/browse/HBASE-19058
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-19058.v0.patch, HBASE-19058.v0.tests.patch
>
>
> see
> [console|https://builds.apache.org/job/PreCommit-HBASE-Build/9259/consoleFull].
>
> {quote}
> 05:38:19 /testptch/patchprocess/precommit/personality/provided.sh: line 121:
> wget: command not found
> 05:38:19 Wget error 127 in fetching excludes file from url
> https://builds.apache.org/job/HBase-Find-Flaky-Tests/lastSuccessfulBuild/artifact/excludes/.
> Ignoring and proceeding.
> 05:38:22 cd /testptch/hbase/hbase-server
> {quote}
> We don't force docker to install {{wget}} before because {{wget}} is in the
> pre-depends of oracle-java8-installer.
> {code}
> $ sudo apt-rdepends oracle-java8-installer | grep "wget"
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> PreDepends: wget
> wget
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19060) "Hadoop check" test is running all the time instead of just when changes to java
[
https://issues.apache.org/jira/browse/HBASE-19060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213782#comment-16213782
]
Hudson commented on HBASE-19060:
FAILURE: Integrated in Jenkins build HBase-1.5 #106 (See
[https://builds.apache.org/job/HBase-1.5/106/])
HBASE-19060 precommit plugin test 'hadoopcheck' should only run when (busbey:
rev 6eb9f4ee8e0d32f4667b04a94a9d46e37e6304ce)
* (edit) dev-support/hbase-personality.sh
> "Hadoop check" test is running all the time instead of just when changes to
> java
>
>
> Key: HBASE-19060
> URL: https://issues.apache.org/jira/browse/HBASE-19060
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-19060.0.patch
>
>
> see for example HBASE-19058, which just changes the dockerfile in dev-support.
> {quote}
> +1hadoopcheck 39m 59s Patch does not cause any errors with Hadoop
> 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4.
> {quote}
> that's 30-40 minutes we're adding to precommit builds that don't need it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19039) refactor shadedjars test to only run on java changes.
[ https://issues.apache.org/jira/browse/HBASE-19039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213783#comment-16213783 ] Hudson commented on HBASE-19039: FAILURE: Integrated in Jenkins build HBase-1.5 #106 (See [https://builds.apache.org/job/HBase-1.5/106/]) HBASE-19039 refactor shadedjars test to only run on java changes. (busbey: rev be2daa12c86fe0fa1ac360125e475c7a8f402a08) * (edit) dev-support/hbase-personality.sh > refactor shadedjars test to only run on java changes. > - > > Key: HBASE-19039 > URL: https://issues.apache.org/jira/browse/HBASE-19039 > Project: HBase > Issue Type: Bug > Components: build >Reporter: Mike Drob >Assignee: Sean Busbey > Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4 > > Attachments: HBASE-19039.0.patch > > > per HBASE-18760 ; the shadejars clean check is currently broken due to a > typo, we should excise it. > needs to be done in all the branches. > Also limit runs of the test to changes that alter poms or java files. > probably that's all that can break this. Any edge cases will come up in > nightly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16338) update jackson to 2.y
[
https://issues.apache.org/jira/browse/HBASE-16338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213780#comment-16213780
]
Hadoop QA commented on HBASE-16338:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
22s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
7s{color} | {color:blue} Shelldocs was not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 17 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
23s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
9s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
22s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 17m
26s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 4m
53s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
58s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: .
hbase-shaded hbase-shaded/hbase-shaded-mapreduce {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
51s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m
52s{color} | {color:green} branch-2 passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
20s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 4m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} rubocop {color} | {color:green} 0m
4s{color} | {color:green} There were no new rubocop issues. {color} |
| {color:green}+1{color} | {color:green} ruby-lint {color} | {color:green} 0m
2s{color} | {color:green} There were no new ruby-lint issues. {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
5s{color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
12s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
19s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
46m 23s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-shaded hbase-shaded/hbase-shaded-mapreduce . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 5m
42s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}135m 45s{color}
| {color:red} root in the
[jira] [Commented] (HBASE-18873) Hide protobufs in GlobalQuotaSettings
[
https://issues.apache.org/jira/browse/HBASE-18873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213764#comment-16213764
]
Hadoop QA commented on HBASE-18873:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 17m
8s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
29s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 8m
20s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
30s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
18s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
57s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 7m
33s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
50s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
19s{color} | {color:green} branch-2 passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
28s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
44s{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} 5m
6s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
55m 17s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
11s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}133m 12s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
5s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}251m 9s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8afa3e |
| JIRA Issue | HBASE-18873 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12893362/HBASE-18873.003.branch-2.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 62a94e2763de 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | branch-2 / d8afa3e |
| Default Java | 1.8.0_141 |
[jira] [Commented] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213765#comment-16213765 ] stack commented on HBASE-19007: --- .013 retry. > Align Services Interfaces in Master and RegionServer > > > Key: HBASE-19007 > URL: https://issues.apache.org/jira/browse/HBASE-19007 > Project: HBase > Issue Type: Task >Reporter: stack >Assignee: stack >Priority: Blocker > Labels: coprocessor > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19007.master.001.patch, > HBASE-19007.master.002.patch, HBASE-19007.master.003.patch, > HBASE-19007.master.004.patch, HBASE-19007.master.005.patch, > HBASE-19007.master.006.patch, HBASE-19007.master.007.patch, > HBASE-19007.master.008.patch, HBASE-19007.master.009.patch, > HBASE-19007.master.009.patch, HBASE-19007.master.010.patch, > HBASE-19007.master.011.patch, HBASE-19007.master.012.patch, > HBASE-19007.master.013.patch > > > HBASE-18183 adds a CoprocessorRegionServerService to give a view on > RegionServiceServices that is safe to expose to Coprocessors. > On the Master-side, MasterServices becomes an Interface for exposing to > Coprocessors. > We need to align the two. > For background, see > https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19007: -- Attachment: HBASE-19007.master.013.patch > Align Services Interfaces in Master and RegionServer > > > Key: HBASE-19007 > URL: https://issues.apache.org/jira/browse/HBASE-19007 > Project: HBase > Issue Type: Task >Reporter: stack >Assignee: stack >Priority: Blocker > Labels: coprocessor > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-19007.master.001.patch, > HBASE-19007.master.002.patch, HBASE-19007.master.003.patch, > HBASE-19007.master.004.patch, HBASE-19007.master.005.patch, > HBASE-19007.master.006.patch, HBASE-19007.master.007.patch, > HBASE-19007.master.008.patch, HBASE-19007.master.009.patch, > HBASE-19007.master.009.patch, HBASE-19007.master.010.patch, > HBASE-19007.master.011.patch, HBASE-19007.master.012.patch, > HBASE-19007.master.013.patch > > > HBASE-18183 adds a CoprocessorRegionServerService to give a view on > RegionServiceServices that is safe to expose to Coprocessors. > On the Master-side, MasterServices becomes an Interface for exposing to > Coprocessors. > We need to align the two. > For background, see > https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19058) The wget isn't installed in building docker image
[
https://issues.apache.org/jira/browse/HBASE-19058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213762#comment-16213762
]
Chia-Ping Tsai commented on HBASE-19058:
Thanks for the reviews. [~busbey] [~mdrob]
> The wget isn't installed in building docker image
> -
>
> Key: HBASE-19058
> URL: https://issues.apache.org/jira/browse/HBASE-19058
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-19058.v0.patch, HBASE-19058.v0.tests.patch
>
>
> see
> [console|https://builds.apache.org/job/PreCommit-HBASE-Build/9259/consoleFull].
>
> {quote}
> 05:38:19 /testptch/patchprocess/precommit/personality/provided.sh: line 121:
> wget: command not found
> 05:38:19 Wget error 127 in fetching excludes file from url
> https://builds.apache.org/job/HBase-Find-Flaky-Tests/lastSuccessfulBuild/artifact/excludes/.
> Ignoring and proceeding.
> 05:38:22 cd /testptch/hbase/hbase-server
> {quote}
> We don't force docker to install {{wget}} before because {{wget}} is in the
> pre-depends of oracle-java8-installer.
> {code}
> $ sudo apt-rdepends oracle-java8-installer | grep "wget"
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> PreDepends: wget
> wget
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type
[
https://issues.apache.org/jira/browse/HBASE-18846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213760#comment-16213760
]
stack commented on HBASE-18846:
---
No. Did not mean to include the hbase-site and sample indexer. Thanks.
Fixed the release note (s/emasculated/hollow/).
Will put up new patch to address your other comments. Thanks for taking a look
[~mdrob]
> Accommodate the hbase-indexer/lily/SEP consumer deploy-type
> ---
>
> Key: HBASE-18846
> URL: https://issues.apache.org/jira/browse/HBASE-18846
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18846.master.001.patch,
> HBASE-18846.master.002.patch, HBASE-18846.master.003.patch,
> HBASE-18846.master.004.patch, IndexerConnection.java, hbase-site.xml,
> javadoc.txt
>
>
> This is a follow-on from HBASE-10504, Define a Replication Interface. There
> we defined a new, flexible replication endpoint for others to implement but
> it did little to help the case of the lily hbase-indexer. This issue takes up
> the case of the hbase-indexer.
> The hbase-indexer poses to hbase as a 'fake' peer cluster (For why
> hbase-indexer is implemented so, the advantage to having the indexing done in
> a separate process set that can be independently scaled, can participate in
> the same security realm, etc., see discussion in HBASE-10504). The
> hbase-indexer will start up a cut-down "RegionServer" processes that are just
> an instance of hbase RpcServer hosting an AdminProtos Service. They make
> themselves 'appear' to the Replication Source by hoisting up an ephemeral
> znode 'registering' as a RegionServer. The source cluster then streams
> WALEdits to the Admin Protos method:
> {code}
> public ReplicateWALEntryResponse replicateWALEntry(final RpcController
> controller,
> final ReplicateWALEntryRequest request) throws ServiceException {
> {code}
> The hbase-indexer relies on other hbase internals like Server so it can get a
> ZooKeeperWatcher instance and know the 'name' to use for this cut-down server.
> Thoughts on how to proceed include:
>
> * Better formalize its current digestion of hbase internals; make it so
> rpcserver is allowed to be used by others, etc. This would be hard to do
> given they use basics like Server, Protobuf serdes for WAL types, and
> AdminProtos Service. Any change in this wide API breaks (again)
> hbase-indexer. We have made a 'channel' for Coprocessor Endpoints so they
> continue to work though they use 'internal' types. They can use protos in
> hbase-protocol. hbase-protocol protos are in a limbo currently where they are
> sort-of 'public'; a TODO. Perhaps the hbase-indexer could do similar relying
> on the hbase-protocol (pb2.5) content and we could do something to reveal
> rpcserver and zk for hbase-indexer safe use.
> * Start an actual RegionServer only have it register the AdminProtos Service
> only -- not ClientProtos and the Service that does Master interaction, etc.
> [I checked, this is not as easy to do as I at first thought -- St.Ack] Then
> have the hbase-indexer implement an AdminCoprocessor to override the
> replicateWALEntry method (the Admin CP implementation may need work). This
> would narrow the hbase-indexer exposure to that of the Admin Coprocessor
> Interface
> * Over in HBASE-10504, [~enis] suggested "... if we want to provide
> isolation for the replication services in hbase, we can have a simple host as
> another daemon which hosts the ReplicationEndpoint implementation. RS's will
> use a built-in RE to send the edits to this layer, and the host will delegate
> it to the RE implementation. The flow would be something like: RS --> RE
> inside RS --> Host daemon for RE --> Actual RE implementation --> third party
> system..."
>
> Other crazy notions occur including the setup of an Admin Interface
> Coprocessor Endpoint. A new ReplicationEndpoint would feed the replication
> stream to the remote cluster via the CPEP registered channel.
> But time is short. Hopefully we can figure something that will work in 2.0
> timeframe w/o too much code movement.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19060) "Hadoop check" test is running all the time instead of just when changes to java
[
https://issues.apache.org/jira/browse/HBASE-19060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213754#comment-16213754
]
Hudson commented on HBASE-19060:
FAILURE: Integrated in Jenkins build HBase-2.0 #722 (See
[https://builds.apache.org/job/HBase-2.0/722/])
HBASE-19060 precommit plugin test 'hadoopcheck' should only run when (busbey:
rev 01ab747a5fbde8604c9893d5959467011679538d)
* (edit) dev-support/hbase-personality.sh
> "Hadoop check" test is running all the time instead of just when changes to
> java
>
>
> Key: HBASE-19060
> URL: https://issues.apache.org/jira/browse/HBASE-19060
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-19060.0.patch
>
>
> see for example HBASE-19058, which just changes the dockerfile in dev-support.
> {quote}
> +1hadoopcheck 39m 59s Patch does not cause any errors with Hadoop
> 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4.
> {quote}
> that's 30-40 minutes we're adding to precommit builds that don't need it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19039) refactor shadedjars test to only run on java changes.
[ https://issues.apache.org/jira/browse/HBASE-19039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213755#comment-16213755 ] Hudson commented on HBASE-19039: FAILURE: Integrated in Jenkins build HBase-2.0 #722 (See [https://builds.apache.org/job/HBase-2.0/722/]) HBASE-19039 refactor shadedjars test to only run on java changes. (busbey: rev a37ff39b7abdd1e7e2406dfa0ebe5b363b4d685d) * (edit) dev-support/hbase-personality.sh > refactor shadedjars test to only run on java changes. > - > > Key: HBASE-19039 > URL: https://issues.apache.org/jira/browse/HBASE-19039 > Project: HBase > Issue Type: Bug > Components: build >Reporter: Mike Drob >Assignee: Sean Busbey > Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4 > > Attachments: HBASE-19039.0.patch > > > per HBASE-18760 ; the shadejars clean check is currently broken due to a > typo, we should excise it. > needs to be done in all the branches. > Also limit runs of the test to changes that alter poms or java files. > probably that's all that can break this. Any edge cases will come up in > nightly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
