[jira] [Commented] (HBASE-15291) FileSystem not closed in secure bulkLoad
[
https://issues.apache.org/jira/browse/HBASE-15291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433721#comment-16433721
]
Hudson commented on HBASE-15291:
Results for branch branch-1
[build #278 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> FileSystem not closed in secure bulkLoad
>
>
> Key: HBASE-15291
> URL: https://issues.apache.org/jira/browse/HBASE-15291
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.2, 0.98.16.1
>Reporter: Yong Zhang
>Assignee: Ashish Singhi
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-15291-branch-1.2.patch,
> HBASE-15291-branch-1.patch, HBASE-15291-revert-master.patch,
> HBASE-15291.001.patch, HBASE-15291.002.patch, HBASE-15291.003.patch,
> HBASE-15291.004.patch, HBASE-15291.addendum, HBASE-15291.patch,
> HBASE-15291.v1.patch, HBASE-15291.v2.patch, HBASE-15291.v2.patch, patch
>
>
> FileSystem not closed in secure bulkLoad after bulkLoad finish, it will
> cause memory used more and more if too many bulkLoad .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-18309) Support multi threads in CleanerChore
[
https://issues.apache.org/jira/browse/HBASE-18309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433718#comment-16433718
]
Hudson commented on HBASE-18309:
Results for branch branch-1
[build #278 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Support multi threads in CleanerChore
> -
>
> Key: HBASE-18309
> URL: https://issues.apache.org/jira/browse/HBASE-18309
> Project: HBase
> Issue Type: Improvement
>Reporter: binlijin
>Assignee: Reid Chan
>Priority: Major
> Fix For: 2.0.0-beta-1, 2.0.0
>
> Attachments: HBASE-18309.addendum.patch,
> HBASE-18309.branch-1.001.patch, HBASE-18309.branch-1.002.patch,
> HBASE-18309.branch-1.003.patch, HBASE-18309.branch-1.004.patch,
> HBASE-18309.branch-1.005.patch, HBASE-18309.branch-1.006.patch,
> HBASE-18309.master.001.patch, HBASE-18309.master.002.patch,
> HBASE-18309.master.004.patch, HBASE-18309.master.005.patch,
> HBASE-18309.master.006.patch, HBASE-18309.master.007.patch,
> HBASE-18309.master.008.patch, HBASE-18309.master.009.patch,
> HBASE-18309.master.010.patch, HBASE-18309.master.011.patch,
> HBASE-18309.master.012.patch, space_consumption_in_archive.png
>
>
> There is only one thread in LogCleaner to clean oldWALs and in our big
> cluster we find this is not enough. The number of files under oldWALs reach
> the max-directory-items limit of HDFS and cause region server crash, so we
> use multi threads for LogCleaner and the crash not happened any more.
> What's more, currently there's only one thread iterating the archive
> directory, and we could use multiple threads cleaning sub directories in
> parallel to speed it up.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20368) Fix RIT stuck when a rsgroup has no online servers but AM's pendingAssginQueue is cleared
[ https://issues.apache.org/jira/browse/HBASE-20368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-20368: --- Attachment: HBASE-20368.branch-2.0.002.patch > Fix RIT stuck when a rsgroup has no online servers but AM's > pendingAssginQueue is cleared > - > > Key: HBASE-20368 > URL: https://issues.apache.org/jira/browse/HBASE-20368 > Project: HBase > Issue Type: Bug > Components: rsgroup >Affects Versions: 2.0.0 >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > Attachments: HBASE-20368.branch-2.0.001.patch, > HBASE-20368.branch-2.0.002.patch, HBASE-20368.branch-2.001.patch > > > This error can be reproduced by shutting down all servers in a rsgroups and > starting them soon afterwards. > The regions on this rsgroup will be reassigned, but there is no available > servers of this rsgroup. > They will be added to AM's pendingAssginQueue, which AM will clear regardless > of the result of assigning in this case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20335) nightly jobs no longer contain machine information
[
https://issues.apache.org/jira/browse/HBASE-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433720#comment-16433720
]
Hudson commented on HBASE-20335:
Results for branch branch-1
[build #278 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> nightly jobs no longer contain machine information
> --
>
> Key: HBASE-20335
> URL: https://issues.apache.org/jira/browse/HBASE-20335
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-20335.0.patch
>
>
> something is up with nightly jobs. they no longer have the machine
> information from HBASE-19228.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20352) [Chore] Backport HBASE-18309 to branch-1
[
https://issues.apache.org/jira/browse/HBASE-20352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433717#comment-16433717
]
Hudson commented on HBASE-20352:
Results for branch branch-1
[build #278 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> [Chore] Backport HBASE-18309 to branch-1
>
>
> Key: HBASE-20352
> URL: https://issues.apache.org/jira/browse/HBASE-20352
> Project: HBase
> Issue Type: Improvement
>Reporter: Reid Chan
>Assignee: Reid Chan
>Priority: Major
> Attachments: HBASE-20352.branch-1.001.patch
>
>
> Using multiple threads to scan directory and to clean old WALs
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20068) Hadoopcheck project health check uses default maven repo instead of yetus managed ones
[
https://issues.apache.org/jira/browse/HBASE-20068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433719#comment-16433719
]
Hudson commented on HBASE-20068:
Results for branch branch-1
[build #278 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/278//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Hadoopcheck project health check uses default maven repo instead of yetus
> managed ones
> --
>
> Key: HBASE-20068
> URL: https://issues.apache.org/jira/browse/HBASE-20068
> Project: HBase
> Issue Type: Bug
> Components: community, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20068.0.patch, HBASE-20068.1.patch
>
>
> Recently had a precommit run fail hadoop check for all 3 versions with
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:2.5.2:install (default-install)
> on project hbase-thrift: Failed to install metadata
> org.apache.hbase:hbase-thrift:3.0.0-SNAPSHOT/maven-metadata.xml: Could not
> parse metadata
> /home/jenkins/.m2/repository/org/apache/hbase/hbase-thrift/3.0.0-SNAPSHOT/maven-metadata-local.xml:
> in epilog non whitespace content is not allowed but got / (position: END_TAG
> seen ...\n/... @25:2) -> [Help 1]
> {code}
> Looks like maven repo corruption.
> Also the path {{/home/jenkins/.m2/repository}} means that those invocations
> are using the jenkins user repo, which isn't safe since there are multiple
> executors. either the plugin isn't using the yetus provided maven repo path
> or our yetus invocation isn't telling yetus to provide its own maven repo
> path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20068) Hadoopcheck project health check uses default maven repo instead of yetus managed ones
[
https://issues.apache.org/jira/browse/HBASE-20068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433751#comment-16433751
]
Hudson commented on HBASE-20068:
Results for branch master
[build #292 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/292/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Hadoopcheck project health check uses default maven repo instead of yetus
> managed ones
> --
>
> Key: HBASE-20068
> URL: https://issues.apache.org/jira/browse/HBASE-20068
> Project: HBase
> Issue Type: Bug
> Components: community, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20068.0.patch, HBASE-20068.1.patch
>
>
> Recently had a precommit run fail hadoop check for all 3 versions with
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:2.5.2:install (default-install)
> on project hbase-thrift: Failed to install metadata
> org.apache.hbase:hbase-thrift:3.0.0-SNAPSHOT/maven-metadata.xml: Could not
> parse metadata
> /home/jenkins/.m2/repository/org/apache/hbase/hbase-thrift/3.0.0-SNAPSHOT/maven-metadata-local.xml:
> in epilog non whitespace content is not allowed but got / (position: END_TAG
> seen ...\n/... @25:2) -> [Help 1]
> {code}
> Looks like maven repo corruption.
> Also the path {{/home/jenkins/.m2/repository}} means that those invocations
> are using the jenkins user repo, which isn't safe since there are multiple
> executors. either the plugin isn't using the yetus provided maven repo path
> or our yetus invocation isn't telling yetus to provide its own maven repo
> path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20372) [website] move stuff from more than 2 years ago to old news
[
https://issues.apache.org/jira/browse/HBASE-20372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433750#comment-16433750
]
Hudson commented on HBASE-20372:
Results for branch master
[build #292 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/292/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> [website] move stuff from more than 2 years ago to old news
> ---
>
> Key: HBASE-20372
> URL: https://issues.apache.org/jira/browse/HBASE-20372
> Project: HBase
> Issue Type: Task
> Components: website
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: HBASE-20372.0.patch
>
>
> "current news" currently covers back to march 2014, which seems too long.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20149) Purge dev javadoc from bin tarball (or make a separate tarball of javadoc)
[
https://issues.apache.org/jira/browse/HBASE-20149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433748#comment-16433748
]
Hudson commented on HBASE-20149:
Results for branch master
[build #292 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/292/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Purge dev javadoc from bin tarball (or make a separate tarball of javadoc)
> --
>
> Key: HBASE-20149
> URL: https://issues.apache.org/jira/browse/HBASE-20149
> Project: HBase
> Issue Type: Sub-task
> Components: build, community, documentation
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20149.branch-2.0.001.patch,
> HBASE-20149.branch-2.0.002.patch, HBASE-20149.branch-2.0.003.patch
>
>
> The bin tarball is too fat (Chia-Ping and Josh noticed it on the beta-2
> vote). A note to the dev list subsequently resulted in suggestion that we
> just purge dev javadoc (or even all javadoc) from bin tarball (Andrew). Sean
> was good w/ it and suggested perhaps we could do a javadoc only tgz. Let me
> look into this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-15291) FileSystem not closed in secure bulkLoad
[
https://issues.apache.org/jira/browse/HBASE-15291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433749#comment-16433749
]
Hudson commented on HBASE-15291:
Results for branch master
[build #292 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/292/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> FileSystem not closed in secure bulkLoad
>
>
> Key: HBASE-15291
> URL: https://issues.apache.org/jira/browse/HBASE-15291
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.2, 0.98.16.1
>Reporter: Yong Zhang
>Assignee: Ashish Singhi
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-15291-branch-1.2.patch,
> HBASE-15291-branch-1.patch, HBASE-15291-revert-master.patch,
> HBASE-15291.001.patch, HBASE-15291.002.patch, HBASE-15291.003.patch,
> HBASE-15291.004.patch, HBASE-15291.addendum, HBASE-15291.patch,
> HBASE-15291.v1.patch, HBASE-15291.v2.patch, HBASE-15291.v2.patch, patch
>
>
> FileSystem not closed in secure bulkLoad after bulkLoad finish, it will
> cause memory used more and more if too many bulkLoad .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20335) nightly jobs no longer contain machine information
[
https://issues.apache.org/jira/browse/HBASE-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433752#comment-16433752
]
Hudson commented on HBASE-20335:
Results for branch master
[build #292 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/292/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/292//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> nightly jobs no longer contain machine information
> --
>
> Key: HBASE-20335
> URL: https://issues.apache.org/jira/browse/HBASE-20335
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-20335.0.patch
>
>
> something is up with nightly jobs. they no longer have the machine
> information from HBASE-19228.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20243) [Shell] Add shell command to create a new table by cloning the existent table
[ https://issues.apache.org/jira/browse/HBASE-20243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433528#comment-16433528 ] Guangxu Cheng commented on HBASE-20243: --- Patch 010 looks good now. [~appy] [~busbey] Any other concerns? Thanks.:) > [Shell] Add shell command to create a new table by cloning the existent table > - > > Key: HBASE-20243 > URL: https://issues.apache.org/jira/browse/HBASE-20243 > Project: HBase > Issue Type: Improvement > Components: shell >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Minor > Fix For: 2.1.0 > > Attachments: HBASE-20243.master.001.patch, > HBASE-20243.master.002.patch, HBASE-20243.master.003.patch, > HBASE-20243.master.004.patch, HBASE-20243.master.005.patch, > HBASE-20243.master.006.patch, HBASE-20243.master.007.patch, > HBASE-20243.master.008.patch, HBASE-20243.master.008.patch, > HBASE-20243.master.009.patch, HBASE-20243.master.010.patch > > > In the production environment, we need to create a new table every day. The > schema and the split keys of the table are the same as that of yesterday's > table, only the name of the table is different. For example, > x_20180321,x_20180322 etc.But now there is no convenient command to > do this. So we may need such a command(clone_table) to create a new table by > cloning the existent table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20386) [DOC] Align WALPlayer help text and refguide
Balazs Meszaros created HBASE-20386: --- Summary: [DOC] Align WALPlayer help text and refguide Key: HBASE-20386 URL: https://issues.apache.org/jira/browse/HBASE-20386 Project: HBase Issue Type: Task Components: documentation Affects Versions: 2.0.0 Reporter: Balazs Meszaros Assignee: Balazs Meszaros -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-15291) FileSystem not closed in secure bulkLoad
[ https://issues.apache.org/jira/browse/HBASE-15291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Singhi updated HBASE-15291: -- Resolution: Fixed Fix Version/s: 2.1.0 Status: Resolved (was: Patch Available) Pushed to branch-1.2+ > FileSystem not closed in secure bulkLoad > > > Key: HBASE-15291 > URL: https://issues.apache.org/jira/browse/HBASE-15291 > Project: HBase > Issue Type: Bug >Affects Versions: 1.0.2, 0.98.16.1 >Reporter: Yong Zhang >Assignee: Ashish Singhi >Priority: Major > Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1 > > Attachments: HBASE-15291-revert-master.patch, HBASE-15291.001.patch, > HBASE-15291.002.patch, HBASE-15291.003.patch, HBASE-15291.004.patch, > HBASE-15291.addendum, HBASE-15291.patch, HBASE-15291.v1.patch, > HBASE-15291.v2.patch, HBASE-15291.v2.patch, patch > > > FileSystem not closed in secure bulkLoad after bulkLoad finish, it will > cause memory used more and more if too many bulkLoad . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20188) [TESTING] Performance
[ https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433700#comment-16433700 ] Eshcar Hillel commented on HBASE-20188: --- Just to summarize the results again -- We see that in write workloads IMC improves performance; it delays flush to disk and hence reduces number of disk compaction. When values are small IMC reduces memory occupancy by reducing metadata size (regardless of workload distribution), when the distribution is skewed IMC reduces memory occupancy by eliminating data duplication (regardless of value size), when the values are big and workload is uniform IMC doesn't help. For reads IMC is either comparable or slightly worse than None (no in-memory compaction). In addition measures we did in past experiments show that IMC reduces write amplification, again due to reducing number of disk compaction. I am opening a new Jira to change the default to the parameters that showed best performance in the recent benchmarks. Namely, IMC policy = ADAPTIVE, active segment porition = 0.02, limit on number of segments in pipeline = 2. We are continuing with our experiments to see if any additional changes can help improve the performance. > [TESTING] Performance > - > > Key: HBASE-20188 > URL: https://issues.apache.org/jira/browse/HBASE-20188 > Project: HBase > Issue Type: Umbrella > Components: Performance >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 2.0.0 > > Attachments: CAM-CONFIG-V01.patch, HBASE-20188-xac.sh, > HBASE-20188.sh, HBase 2.0 performance evaluation - 8GB(1).pdf, HBase 2.0 > performance evaluation - 8GB.pdf, HBase 2.0 performance evaluation - Basic vs > None_ system settings.pdf, ITBLL2.5B_1.2.7vs2.0.0_cpu.png, > ITBLL2.5B_1.2.7vs2.0.0_gctime.png, ITBLL2.5B_1.2.7vs2.0.0_iops.png, > ITBLL2.5B_1.2.7vs2.0.0_load.png, ITBLL2.5B_1.2.7vs2.0.0_memheap.png, > ITBLL2.5B_1.2.7vs2.0.0_memstore.png, ITBLL2.5B_1.2.7vs2.0.0_ops.png, > ITBLL2.5B_1.2.7vs2.0.0_ops_NOT_summing_regions.png, YCSB_CPU.png, > YCSB_GC_TIME.png, YCSB_IN_MEMORY_COMPACTION=NONE.ops.png, YCSB_MEMSTORE.png, > YCSB_OPs.png, YCSB_in-memory-compaction=NONE.ops.png, YCSB_load.png, > flamegraph-1072.1.svg, flamegraph-1072.2.svg, hbase-env.sh, hbase-site.xml, > hbase-site.xml, lock.127.workloadc.20180402T200918Z.svg, > lock.2.memsize2.c.20180403T160257Z.svg, run_ycsb.sh, tree.txt, workloadx, > workloadx > > > How does 2.0.0 compare to old versions? Is it faster, slower? There is rumor > that it is much slower, that the problem is the asyncwal writing. Does > in-memory compaction slow us down or speed us up? What happens when you > enable offheaping? > Keep notes here in this umbrella issue. Need to be able to say something > about perf when 2.0.0 ships. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-18620) Secure bulkload job fails when HDFS umask has limited scope
[
https://issues.apache.org/jira/browse/HBASE-18620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433522#comment-16433522
]
Hadoop QA commented on HBASE-18620:
---
| (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:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 8m
6s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
41s{color} | {color:green} branch-1 passed with JDK v1.8.0_163 {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
17s{color} | {color:red} hbase-server in branch-1 failed with JDK v1.7.0_171.
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
22s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
37s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} branch-1 passed with JDK v1.8.0_163 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} branch-1 passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
30s{color} | {color:green} the patch passed with JDK v1.8.0_163 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
30s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
17s{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_171.
{color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 17s{color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_171. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
1s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
32s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 0m
55s{color} | {color:red} The patch causes 44 errors with Hadoop v2.4.1. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
48s{color} | {color:red} The patch causes 44 errors with Hadoop v2.5.2. {color}
|
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} the patch passed with JDK v1.8.0_163 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} the patch passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}102m 5s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
30s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}131m 23s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.replication.regionserver.TestGlobalThrottler |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:36a7029 |
| JIRA Issue |
[jira] [Assigned] (HBASE-20378) Provide a hbck option to cleanup replication barrier for a table
[ https://issues.apache.org/jira/browse/HBASE-20378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian reassigned HBASE-20378: Assignee: Jingyun Tian > Provide a hbck option to cleanup replication barrier for a table > > > Key: HBASE-20378 > URL: https://issues.apache.org/jira/browse/HBASE-20378 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Jingyun Tian >Priority: Major > > It is not easy to deal with the scenario where a user change the replication > scope from global to local since it may change the scope back while we are > cleaning in the background. And I think this a rare operation so just provide > an hbck option to deal with it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-15291) FileSystem not closed in secure bulkLoad
[ https://issues.apache.org/jira/browse/HBASE-15291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433621#comment-16433621 ] Hudson commented on HBASE-15291: SUCCESS: Integrated in Jenkins build HBase-1.2-IT #1101 (See [https://builds.apache.org/job/HBase-1.2-IT/1101/]) HBASE-15291 FileSystem not closed in secure bulkLoad (ashishsinghi: rev 2954aeae2d10a35fdde0d619640a563dcc33f79c) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/SecureBulkLoadEndpoint.java > FileSystem not closed in secure bulkLoad > > > Key: HBASE-15291 > URL: https://issues.apache.org/jira/browse/HBASE-15291 > Project: HBase > Issue Type: Bug >Affects Versions: 1.0.2, 0.98.16.1 >Reporter: Yong Zhang >Assignee: Ashish Singhi >Priority: Major > Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1 > > Attachments: HBASE-15291-branch-1.2.patch, > HBASE-15291-branch-1.patch, HBASE-15291-revert-master.patch, > HBASE-15291.001.patch, HBASE-15291.002.patch, HBASE-15291.003.patch, > HBASE-15291.004.patch, HBASE-15291.addendum, HBASE-15291.patch, > HBASE-15291.v1.patch, HBASE-15291.v2.patch, HBASE-15291.v2.patch, patch > > > FileSystem not closed in secure bulkLoad after bulkLoad finish, it will > cause memory used more and more if too many bulkLoad . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-18812) Recategorize some of classes used as tools
[ https://issues.apache.org/jira/browse/HBASE-18812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433559#comment-16433559 ] Guangxu Cheng commented on HBASE-18812: --- hi, [~chia7712]. I reviewed the whole codebase and Maybe all the following classes should be marked as HBaseInterfaceAudience.TOOLS. WDYT?:) # AcidGuaranteesTestTool # BackupDriver # Canary # CellCounter # Compressor # CopyTable # CreateSnapshot # DumpReplicationQueues # ExpiredMobFileCleaner # Export # ExportSnapshot # HashTable # Import # ImportTsv # IndexBuilder # IntegrationTestAcidGuarantees # IntegrationTestBackupRestore # IntegrationTestBase # IntegrationTestBigLinkedList # IntegrationTestBulkLoad # IntegrationTestDDLMasterFailover # IntegrationTestIngest # IntegrationTestIngestWithMOB # IntegrationTestLoadAndVerify # IntegrationTestRegionReplicaPerf # IntegrationTestRegionReplicaReplication # IntegrationTestsDriver # IntegrationTestSendTraceRequests # IntegrationTestSparkBulkLoad # IntegrationTestTableSnapshotInputFormat # IntegrationTestTimeBoundedMultiGetRequestsWithRegionReplicas # IntegrationTestTimeBoundedRequestsWithRegionReplicas # IntegrationTestZKAndFSPermissions # LoadIncrementalHFiles # LoadIncrementalHFiles # MapReduceHFileSplitterJob # MasterProcedureSchedulerPerformanceEvaluation # MultiThreadedClientExample # PerformanceEvaluation # ProcedureWALLoaderPerformanceEvaluation # ProcedureWALPerformanceEvaluation # RegionMover # ReplicationSyncUp # RestartMetaTest # RestoreDriver # RowCounter # SampleUploader # ScanPerformanceEvaluation # ServerCommandLine # SnapshotInfo # StripeCompactionsPerformanceEvaluation # SyncTable # TestTool # VerifyReplication # VersionInfo # WALPerformanceEvaluation # WALPlayer # ZkAclReset # BufferedMutatorExample # AsyncClientExample # MultiThreadedClientExample # HttpProxyExample # ExportEndpointExample # JavaHBaseBulkLoadExample # JavaHBaseStreamingBulkPutExample # JavaHBaseBulkDeleteExample # JavaHBaseBulkPutExample # JavaHBaseBulkGetExample # JavaHBaseMapGetPutExample > Recategorize some of classes used as tools > -- > > Key: HBASE-18812 > URL: https://issues.apache.org/jira/browse/HBASE-18812 > Project: HBase > Issue Type: Task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Major > > The classes used from cmd line should be made as LimitedPrivate.TOOLS. The > candidates are shown below. > # BackupDriver > # RestoreDriver > # CreateSnapshot > # SnapshotInfo > # ExportSnapshot > # Canary > # VersionInfo > # RegionMover > # CellCounter > # CopyTable > # DumpReplicationQueues > # Export > # HashTable > # Import > # ImportTsv > # LoadIncrementalHFiles > # ReplicationSyncUp > # SyncTable > # VerifyReplication > # WALPlayer > # ZkAclReset -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20151) Bug with SingleColumnValueFilter and FamilyFilter
[
https://issues.apache.org/jira/browse/HBASE-20151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reid Chan updated HBASE-20151:
--
Attachment: HBASE-20151.master.003.patch
> Bug with SingleColumnValueFilter and FamilyFilter
> -
>
> Key: HBASE-20151
> URL: https://issues.apache.org/jira/browse/HBASE-20151
> Project: HBase
> Issue Type: Bug
> Environment: MacOS 10.13.3
> HBase 1.3.1
>Reporter: Steven Sadowski
>Assignee: Reid Chan
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20151.master.001.patch,
> HBASE-20151.master.002.patch, HBASE-20151.master.003.patch
>
>
> When running the following queries, the result is sometimes return correctly
> and other times incorrectly based on the qualifier queried.
> Setup:
> {code:java}
> create 'test', 'a', 'b'
> test = get_table 'test'
> test.put '1', 'a:1', nil
> test.put '1', 'a:10', nil
> test.put '1', 'b:2', nil
> {code}
>
> This query works fine when the SCVF's qualifier has length 1 (i.e. '1') :
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','1',=,'binary:',true,true) AND
> FamilyFilter(=,'binary:b') )"})
> ROW COLUMN+CELL
> 1column=b:2,
> timestamp=1520455888059, value=
> 1 row(s) in 0.0060 seconds
> {code}
>
> The query should return the same result when passed a qualifier of length 2
> (i.e. '10') :
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','10',=,'binary:',true,true) AND
> FamilyFilter(=,'binary:b') )"})
> ROW COLUMN+CELL
> 0 row(s) in 0.0110 seconds
> {code}
> However, in this case, it does not return any row (expected result would be
> to return the same result as the first query).
>
> Removing the family filter while the qualifier is '10' yields expected
> results:
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','10',=,'binary:',true,true) )"})
> ROW COLUMN+CELL
> 1column=a:1,
> timestamp=1520455887954, value=
> 1column=a:10,
> timestamp=1520455888024, value=
> 1column=b:2,
> timestamp=1520455888059, value=
> 1 row(s) in 0.0140 seconds
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20151) Bug with SingleColumnValueFilter and FamilyFilter
[
https://issues.apache.org/jira/browse/HBASE-20151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433689#comment-16433689
]
Reid Chan edited comment on HBASE-20151 at 4/11/18 10:18 AM:
-
HBASE-20068 is fixed, thanks Sean for reminder.
Trigger QA again.
was (Author: reidchan):
HBase-20068 is fixed, thanks Sean for reminder.
Trigger QA again.
> Bug with SingleColumnValueFilter and FamilyFilter
> -
>
> Key: HBASE-20151
> URL: https://issues.apache.org/jira/browse/HBASE-20151
> Project: HBase
> Issue Type: Bug
> Environment: MacOS 10.13.3
> HBase 1.3.1
>Reporter: Steven Sadowski
>Assignee: Reid Chan
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20151.master.001.patch,
> HBASE-20151.master.002.patch, HBASE-20151.master.003.patch
>
>
> When running the following queries, the result is sometimes return correctly
> and other times incorrectly based on the qualifier queried.
> Setup:
> {code:java}
> create 'test', 'a', 'b'
> test = get_table 'test'
> test.put '1', 'a:1', nil
> test.put '1', 'a:10', nil
> test.put '1', 'b:2', nil
> {code}
>
> This query works fine when the SCVF's qualifier has length 1 (i.e. '1') :
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','1',=,'binary:',true,true) AND
> FamilyFilter(=,'binary:b') )"})
> ROW COLUMN+CELL
> 1column=b:2,
> timestamp=1520455888059, value=
> 1 row(s) in 0.0060 seconds
> {code}
>
> The query should return the same result when passed a qualifier of length 2
> (i.e. '10') :
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','10',=,'binary:',true,true) AND
> FamilyFilter(=,'binary:b') )"})
> ROW COLUMN+CELL
> 0 row(s) in 0.0110 seconds
> {code}
> However, in this case, it does not return any row (expected result would be
> to return the same result as the first query).
>
> Removing the family filter while the qualifier is '10' yields expected
> results:
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','10',=,'binary:',true,true) )"})
> ROW COLUMN+CELL
> 1column=a:1,
> timestamp=1520455887954, value=
> 1column=a:10,
> timestamp=1520455888024, value=
> 1column=b:2,
> timestamp=1520455888059, value=
> 1 row(s) in 0.0140 seconds
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20151) Bug with SingleColumnValueFilter and FamilyFilter
[
https://issues.apache.org/jira/browse/HBASE-20151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433689#comment-16433689
]
Reid Chan commented on HBASE-20151:
---
HBase-20068 is fixed, thanks Sean for reminder.
Trigger QA again.
> Bug with SingleColumnValueFilter and FamilyFilter
> -
>
> Key: HBASE-20151
> URL: https://issues.apache.org/jira/browse/HBASE-20151
> Project: HBase
> Issue Type: Bug
> Environment: MacOS 10.13.3
> HBase 1.3.1
>Reporter: Steven Sadowski
>Assignee: Reid Chan
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20151.master.001.patch,
> HBASE-20151.master.002.patch, HBASE-20151.master.003.patch
>
>
> When running the following queries, the result is sometimes return correctly
> and other times incorrectly based on the qualifier queried.
> Setup:
> {code:java}
> create 'test', 'a', 'b'
> test = get_table 'test'
> test.put '1', 'a:1', nil
> test.put '1', 'a:10', nil
> test.put '1', 'b:2', nil
> {code}
>
> This query works fine when the SCVF's qualifier has length 1 (i.e. '1') :
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','1',=,'binary:',true,true) AND
> FamilyFilter(=,'binary:b') )"})
> ROW COLUMN+CELL
> 1column=b:2,
> timestamp=1520455888059, value=
> 1 row(s) in 0.0060 seconds
> {code}
>
> The query should return the same result when passed a qualifier of length 2
> (i.e. '10') :
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','10',=,'binary:',true,true) AND
> FamilyFilter(=,'binary:b') )"})
> ROW COLUMN+CELL
> 0 row(s) in 0.0110 seconds
> {code}
> However, in this case, it does not return any row (expected result would be
> to return the same result as the first query).
>
> Removing the family filter while the qualifier is '10' yields expected
> results:
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','10',=,'binary:',true,true) )"})
> ROW COLUMN+CELL
> 1column=a:1,
> timestamp=1520455887954, value=
> 1column=a:10,
> timestamp=1520455888024, value=
> 1column=b:2,
> timestamp=1520455888059, value=
> 1 row(s) in 0.0140 seconds
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20368) Fix RIT stuck when a rsgroup has no online servers but AM's pendingAssginQueue is cleared
[ https://issues.apache.org/jira/browse/HBASE-20368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433725#comment-16433725 ] Xiaolin Ha commented on HBASE-20368: Sorry, my wrong localhost's environment made some UTs fail as I has mentioned before. I have uploaded new patches. > Fix RIT stuck when a rsgroup has no online servers but AM's > pendingAssginQueue is cleared > - > > Key: HBASE-20368 > URL: https://issues.apache.org/jira/browse/HBASE-20368 > Project: HBase > Issue Type: Bug > Components: rsgroup >Affects Versions: 2.0.0 >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > Attachments: HBASE-20368.branch-2.0.001.patch, > HBASE-20368.branch-2.0.003.patch, HBASE-20368.branch-2.001.patch > > > This error can be reproduced by shutting down all servers in a rsgroups and > starting them soon afterwards. > The regions on this rsgroup will be reassigned, but there is no available > servers of this rsgroup. > They will be added to AM's pendingAssginQueue, which AM will clear regardless > of the result of assigning in this case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19079) Support setting up two clusters with A and S state
[ https://issues.apache.org/jira/browse/HBASE-19079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19079: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to branch HBASE-19064. Thanks [~openinx] for reviewing. > Support setting up two clusters with A and S state > -- > > Key: HBASE-19079 > URL: https://issues.apache.org/jira/browse/HBASE-19079 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Labels: HBASE-19064 > Fix For: HBASE-19064 > > Attachments: HBASE-19079-HBASE-19064-v1.patch, > HBASE-19079-HBASE-19064-v2.patch, HBASE-19079-HBASE-19064-v4.patch, > HBASE-19079-HBASE-19064.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20367) Write a replication barrier for regions when disabling a table
[ https://issues.apache.org/jira/browse/HBASE-20367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433516#comment-16433516 ] Duo Zhang commented on HBASE-20367: --- Any concerns? [~openinx] [~zghaobac]. Thanks. > Write a replication barrier for regions when disabling a table > -- > > Key: HBASE-20367 > URL: https://issues.apache.org/jira/browse/HBASE-20367 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.1.0 > > Attachments: HBASE-20367.patch > > > So that we can use the same algorithm for split/merged regions to remove the > barriers when replication is done. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20386) [DOC] Align WALPlayer help text and refguide
[ https://issues.apache.org/jira/browse/HBASE-20386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Meszaros updated HBASE-20386: Fix Version/s: 3.0.0 Status: Patch Available (was: Open) > [DOC] Align WALPlayer help text and refguide > > > Key: HBASE-20386 > URL: https://issues.apache.org/jira/browse/HBASE-20386 > Project: HBase > Issue Type: Task > Components: documentation >Affects Versions: 2.0.0 >Reporter: Balazs Meszaros >Assignee: Balazs Meszaros >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20386.master.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20253) Error message is missing for restore_snapshot
[
https://issues.apache.org/jira/browse/HBASE-20253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi updated HBASE-20253:
--
Attachment: HBASE-20253.master.004.patch
> Error message is missing for restore_snapshot
> -
>
> Key: HBASE-20253
> URL: https://issues.apache.org/jira/browse/HBASE-20253
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Minor
> Attachments: HBASE-20253.master.001.patch,
> HBASE-20253.master.002.patch, HBASE-20253.master.003.patch,
> HBASE-20253.master.004.patch
>
>
> When the table is not disabled and restore_snapshot executed the error
> message is useless, only displays the table name.
> hbase(main):007:0> restore_snapshot 'tsnap'
> ERROR: t
> Restore a specified snapshot.
> The restore will replace the content of the original table,
> bringing back the content to the snapshot state.
> The table must be disabled.
> Examples:
> hbase> restore_snapshot 'snapshotName'
> Following command will restore all acl from snapshot table into the table.
> hbase> restore_snapshot 'snapshotName', \{RESTORE_ACL=>true}
> Took 0.1044 seconds
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20368) Fix RIT stuck when a rsgroup has no online servers but AM's pendingAssginQueue is cleared
[ https://issues.apache.org/jira/browse/HBASE-20368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-20368: --- Attachment: HBASE-20368.branch-2.001.patch > Fix RIT stuck when a rsgroup has no online servers but AM's > pendingAssginQueue is cleared > - > > Key: HBASE-20368 > URL: https://issues.apache.org/jira/browse/HBASE-20368 > Project: HBase > Issue Type: Bug > Components: rsgroup >Affects Versions: 2.0.0 >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > Attachments: HBASE-20368.branch-2.0.001.patch, > HBASE-20368.branch-2.001.patch > > > This error can be reproduced by shutting down all servers in a rsgroups and > starting them soon afterwards. > The regions on this rsgroup will be reassigned, but there is no available > servers of this rsgroup. > They will be added to AM's pendingAssginQueue, which AM will clear regardless > of the result of assigning in this case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20386) [DOC] Align WALPlayer help text and refguide
[ https://issues.apache.org/jira/browse/HBASE-20386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Meszaros updated HBASE-20386: Attachment: HBASE-20386.master.001.patch > [DOC] Align WALPlayer help text and refguide > > > Key: HBASE-20386 > URL: https://issues.apache.org/jira/browse/HBASE-20386 > Project: HBase > Issue Type: Task > Components: documentation >Affects Versions: 2.0.0 >Reporter: Balazs Meszaros >Assignee: Balazs Meszaros >Priority: Minor > Attachments: HBASE-20386.master.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20253) Error message is missing for restore_snapshot
[
https://issues.apache.org/jira/browse/HBASE-20253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433615#comment-16433615
]
Peter Somogyi commented on HBASE-20253:
---
I fixed the rubocop issues in admin_test.rb. I'd prefer not to touch
commands.rb, these issues were there before.
> Error message is missing for restore_snapshot
> -
>
> Key: HBASE-20253
> URL: https://issues.apache.org/jira/browse/HBASE-20253
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Minor
> Attachments: HBASE-20253.master.001.patch,
> HBASE-20253.master.002.patch, HBASE-20253.master.003.patch,
> HBASE-20253.master.004.patch
>
>
> When the table is not disabled and restore_snapshot executed the error
> message is useless, only displays the table name.
> hbase(main):007:0> restore_snapshot 'tsnap'
> ERROR: t
> Restore a specified snapshot.
> The restore will replace the content of the original table,
> bringing back the content to the snapshot state.
> The table must be disabled.
> Examples:
> hbase> restore_snapshot 'snapshotName'
> Following command will restore all acl from snapshot table into the table.
> hbase> restore_snapshot 'snapshotName', \{RESTORE_ACL=>true}
> Took 0.1044 seconds
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20151) Bug with SingleColumnValueFilter and FamilyFilter
[
https://issues.apache.org/jira/browse/HBASE-20151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reid Chan updated HBASE-20151:
--
Attachment: (was: HBASE-20151.master.003.patch)
> Bug with SingleColumnValueFilter and FamilyFilter
> -
>
> Key: HBASE-20151
> URL: https://issues.apache.org/jira/browse/HBASE-20151
> Project: HBase
> Issue Type: Bug
> Environment: MacOS 10.13.3
> HBase 1.3.1
>Reporter: Steven Sadowski
>Assignee: Reid Chan
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20151.master.001.patch,
> HBASE-20151.master.002.patch
>
>
> When running the following queries, the result is sometimes return correctly
> and other times incorrectly based on the qualifier queried.
> Setup:
> {code:java}
> create 'test', 'a', 'b'
> test = get_table 'test'
> test.put '1', 'a:1', nil
> test.put '1', 'a:10', nil
> test.put '1', 'b:2', nil
> {code}
>
> This query works fine when the SCVF's qualifier has length 1 (i.e. '1') :
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','1',=,'binary:',true,true) AND
> FamilyFilter(=,'binary:b') )"})
> ROW COLUMN+CELL
> 1column=b:2,
> timestamp=1520455888059, value=
> 1 row(s) in 0.0060 seconds
> {code}
>
> The query should return the same result when passed a qualifier of length 2
> (i.e. '10') :
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','10',=,'binary:',true,true) AND
> FamilyFilter(=,'binary:b') )"})
> ROW COLUMN+CELL
> 0 row(s) in 0.0110 seconds
> {code}
> However, in this case, it does not return any row (expected result would be
> to return the same result as the first query).
>
> Removing the family filter while the qualifier is '10' yields expected
> results:
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','10',=,'binary:',true,true) )"})
> ROW COLUMN+CELL
> 1column=a:1,
> timestamp=1520455887954, value=
> 1column=a:10,
> timestamp=1520455888024, value=
> 1column=b:2,
> timestamp=1520455888059, value=
> 1 row(s) in 0.0140 seconds
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20188) [TESTING] Performance
[ https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433704#comment-16433704 ] Eshcar Hillel commented on HBASE-20188: --- re-attaching [^workloadx] from the most recent experiment > [TESTING] Performance > - > > Key: HBASE-20188 > URL: https://issues.apache.org/jira/browse/HBASE-20188 > Project: HBase > Issue Type: Umbrella > Components: Performance >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 2.0.0 > > Attachments: CAM-CONFIG-V01.patch, HBASE-20188-xac.sh, > HBASE-20188.sh, HBase 2.0 performance evaluation - 8GB(1).pdf, HBase 2.0 > performance evaluation - 8GB.pdf, HBase 2.0 performance evaluation - Basic vs > None_ system settings.pdf, ITBLL2.5B_1.2.7vs2.0.0_cpu.png, > ITBLL2.5B_1.2.7vs2.0.0_gctime.png, ITBLL2.5B_1.2.7vs2.0.0_iops.png, > ITBLL2.5B_1.2.7vs2.0.0_load.png, ITBLL2.5B_1.2.7vs2.0.0_memheap.png, > ITBLL2.5B_1.2.7vs2.0.0_memstore.png, ITBLL2.5B_1.2.7vs2.0.0_ops.png, > ITBLL2.5B_1.2.7vs2.0.0_ops_NOT_summing_regions.png, YCSB_CPU.png, > YCSB_GC_TIME.png, YCSB_IN_MEMORY_COMPACTION=NONE.ops.png, YCSB_MEMSTORE.png, > YCSB_OPs.png, YCSB_in-memory-compaction=NONE.ops.png, YCSB_load.png, > flamegraph-1072.1.svg, flamegraph-1072.2.svg, hbase-env.sh, hbase-site.xml, > hbase-site.xml, lock.127.workloadc.20180402T200918Z.svg, > lock.2.memsize2.c.20180403T160257Z.svg, run_ycsb.sh, tree.txt, workloadx, > workloadx > > > How does 2.0.0 compare to old versions? Is it faster, slower? There is rumor > that it is much slower, that the problem is the asyncwal writing. Does > in-memory compaction slow us down or speed us up? What happens when you > enable offheaping? > Keep notes here in this umbrella issue. Need to be able to say something > about perf when 2.0.0 ships. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20188) [TESTING] Performance
[ https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eshcar Hillel updated HBASE-20188: -- Attachment: workloadx > [TESTING] Performance > - > > Key: HBASE-20188 > URL: https://issues.apache.org/jira/browse/HBASE-20188 > Project: HBase > Issue Type: Umbrella > Components: Performance >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 2.0.0 > > Attachments: CAM-CONFIG-V01.patch, HBASE-20188-xac.sh, > HBASE-20188.sh, HBase 2.0 performance evaluation - 8GB(1).pdf, HBase 2.0 > performance evaluation - 8GB.pdf, HBase 2.0 performance evaluation - Basic vs > None_ system settings.pdf, ITBLL2.5B_1.2.7vs2.0.0_cpu.png, > ITBLL2.5B_1.2.7vs2.0.0_gctime.png, ITBLL2.5B_1.2.7vs2.0.0_iops.png, > ITBLL2.5B_1.2.7vs2.0.0_load.png, ITBLL2.5B_1.2.7vs2.0.0_memheap.png, > ITBLL2.5B_1.2.7vs2.0.0_memstore.png, ITBLL2.5B_1.2.7vs2.0.0_ops.png, > ITBLL2.5B_1.2.7vs2.0.0_ops_NOT_summing_regions.png, YCSB_CPU.png, > YCSB_GC_TIME.png, YCSB_IN_MEMORY_COMPACTION=NONE.ops.png, YCSB_MEMSTORE.png, > YCSB_OPs.png, YCSB_in-memory-compaction=NONE.ops.png, YCSB_load.png, > flamegraph-1072.1.svg, flamegraph-1072.2.svg, hbase-env.sh, hbase-site.xml, > hbase-site.xml, lock.127.workloadc.20180402T200918Z.svg, > lock.2.memsize2.c.20180403T160257Z.svg, run_ycsb.sh, tree.txt, workloadx, > workloadx > > > How does 2.0.0 compare to old versions? Is it faster, slower? There is rumor > that it is much slower, that the problem is the asyncwal writing. Does > in-memory compaction slow us down or speed us up? What happens when you > enable offheaping? > Keep notes here in this umbrella issue. Need to be able to say something > about perf when 2.0.0 ships. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20368) Fix RIT stuck when a rsgroup has no online servers but AM's pendingAssginQueue is cleared
[ https://issues.apache.org/jira/browse/HBASE-20368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-20368: --- Attachment: HBASE-20368.branch-2.0.003.patch > Fix RIT stuck when a rsgroup has no online servers but AM's > pendingAssginQueue is cleared > - > > Key: HBASE-20368 > URL: https://issues.apache.org/jira/browse/HBASE-20368 > Project: HBase > Issue Type: Bug > Components: rsgroup >Affects Versions: 2.0.0 >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > Attachments: HBASE-20368.branch-2.0.001.patch, > HBASE-20368.branch-2.0.002.patch, HBASE-20368.branch-2.0.003.patch, > HBASE-20368.branch-2.001.patch > > > This error can be reproduced by shutting down all servers in a rsgroups and > starting them soon afterwards. > The regions on this rsgroup will be reassigned, but there is no available > servers of this rsgroup. > They will be added to AM's pendingAssginQueue, which AM will clear regardless > of the result of assigning in this case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20368) Fix RIT stuck when a rsgroup has no online servers but AM's pendingAssginQueue is cleared
[ https://issues.apache.org/jira/browse/HBASE-20368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-20368: --- Attachment: (was: HBASE-20368.branch-2.0.002.patch) > Fix RIT stuck when a rsgroup has no online servers but AM's > pendingAssginQueue is cleared > - > > Key: HBASE-20368 > URL: https://issues.apache.org/jira/browse/HBASE-20368 > Project: HBase > Issue Type: Bug > Components: rsgroup >Affects Versions: 2.0.0 >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > Attachments: HBASE-20368.branch-2.0.001.patch, > HBASE-20368.branch-2.0.003.patch, HBASE-20368.branch-2.001.patch > > > This error can be reproduced by shutting down all servers in a rsgroups and > starting them soon afterwards. > The regions on this rsgroup will be reassigned, but there is no available > servers of this rsgroup. > They will be added to AM's pendingAssginQueue, which AM will clear regardless > of the result of assigning in this case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20352) [Chore] Backport HBASE-18309 to branch-1
[ https://issues.apache.org/jira/browse/HBASE-20352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-20352: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 1.4.4 1.5.0 Status: Resolved (was: Patch Available) Thanks for the release note [~reidchan]. I've also pushed the commit to branch-1.4. Since all work done here, closing as Fixed. > [Chore] Backport HBASE-18309 to branch-1 > > > Key: HBASE-20352 > URL: https://issues.apache.org/jira/browse/HBASE-20352 > Project: HBase > Issue Type: Improvement >Reporter: Reid Chan >Assignee: Reid Chan >Priority: Major > Fix For: 1.5.0, 1.4.4 > > Attachments: HBASE-20352.branch-1.001.patch > > > Using multiple threads to scan directory and to clean old WALs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20243) [Shell] Add shell command to create a new table by cloning the existent table
[
https://issues.apache.org/jira/browse/HBASE-20243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433514#comment-16433514
]
Hadoop QA commented on HBASE-20243:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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 4 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
22s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
48s{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
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
2s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} rubocop {color} | {color:green} 0m
17s{color} | {color:green} The patch generated 0 new + 767 unchanged - 16 fixed
= 767 total (was 783) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
21s{color} | {color:red} The patch generated 52 new + 1274 unchanged - 3 fixed
= 1326 total (was 1277) {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
49s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 14s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
3s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
3s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}107m
44s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m
1s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
55s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}172m 49s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20243 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12918504/HBASE-20243.master.010.patch
|
| Optional Tests | asflicense javac
[jira] [Commented] (HBASE-15291) FileSystem not closed in secure bulkLoad
[ https://issues.apache.org/jira/browse/HBASE-15291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433554#comment-16433554 ] Hudson commented on HBASE-15291: SUCCESS: Integrated in Jenkins build HBase-1.3-IT #393 (See [https://builds.apache.org/job/HBase-1.3-IT/393/]) HBASE-15291 FileSystem not closed in secure bulkLoad (ashishsinghi: rev e0536bfc554a6a5081005c6fd0d8741081ff647a) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/SecureBulkLoadEndpoint.java > FileSystem not closed in secure bulkLoad > > > Key: HBASE-15291 > URL: https://issues.apache.org/jira/browse/HBASE-15291 > Project: HBase > Issue Type: Bug >Affects Versions: 1.0.2, 0.98.16.1 >Reporter: Yong Zhang >Assignee: Ashish Singhi >Priority: Major > Fix For: 3.0.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1 > > Attachments: HBASE-15291-revert-master.patch, HBASE-15291.001.patch, > HBASE-15291.002.patch, HBASE-15291.003.patch, HBASE-15291.004.patch, > HBASE-15291.addendum, HBASE-15291.patch, HBASE-15291.v1.patch, > HBASE-15291.v2.patch, HBASE-15291.v2.patch, patch > > > FileSystem not closed in secure bulkLoad after bulkLoad finish, it will > cause memory used more and more if too many bulkLoad . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HBASE-20382) If RSGroups not enabled, rsgroup.jsp prints stack trace
[
https://issues.apache.org/jira/browse/HBASE-20382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balazs Meszaros reassigned HBASE-20382:
---
Assignee: Balazs Meszaros
> If RSGroups not enabled, rsgroup.jsp prints stack trace
> ---
>
> Key: HBASE-20382
> URL: https://issues.apache.org/jira/browse/HBASE-20382
> Project: HBase
> Issue Type: Bug
> Components: rsgroup, UI
>Reporter: Mike Drob
>Assignee: Balazs Meszaros
>Priority: Major
> Labels: beginner
> Fix For: 2.0.0
>
>
> Going to {{rsgroup.jsp?name=foo}} I get the following stack trace:
> {noformat}
> org.apache.hadoop.hbase.TableNotFoundException: hbase:rsgroup
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegionInMeta(ConnectionImplementation.java:842)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:733)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:719)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:690)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.getRegionLocation(ConnectionImplementation.java:571)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.getRegionLocation(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.HRegionLocator.getRegionLocation(HRegionLocator.java:73)
> at
> org.apache.hadoop.hbase.client.RegionServerCallable.prepare(RegionServerCallable.java:223)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCallerImpl.callWithRetries(RpcRetryingCallerImpl.java:105)
> at org.apache.hadoop.hbase.client.HTable.get(HTable.java:385)
> at org.apache.hadoop.hbase.client.HTable.get(HTable.java:359)
> at
> org.apache.hadoop.hbase.RSGroupTableAccessor.getRSGroupInfo(RSGroupTableAccessor.java:75)
> at
> org.apache.hadoop.hbase.generated.master.rsgroup_jsp._jspService(rsgroup_jsp.java:78)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:840)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1772)
> at
> org.apache.hadoop.hbase.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:112)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.ClickjackingPreventionFilter.doFilter(ClickjackingPreventionFilter.java:48)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:1374)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.NoCacheFilter.doFilter(NoCacheFilter.java:49)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.NoCacheFilter.doFilter(NoCacheFilter.java:49)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at
>
[jira] [Commented] (HBASE-15291) FileSystem not closed in secure bulkLoad
[ https://issues.apache.org/jira/browse/HBASE-15291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433610#comment-16433610 ] Ashish Singhi commented on HBASE-15291: --- Attached branch-1 patch which I pushed to branch-1.3, branch-1.4 and branch-1.5. and branch-1.2 patch for branch-1.2 for reference. > FileSystem not closed in secure bulkLoad > > > Key: HBASE-15291 > URL: https://issues.apache.org/jira/browse/HBASE-15291 > Project: HBase > Issue Type: Bug >Affects Versions: 1.0.2, 0.98.16.1 >Reporter: Yong Zhang >Assignee: Ashish Singhi >Priority: Major > Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1 > > Attachments: HBASE-15291-branch-1.2.patch, > HBASE-15291-branch-1.patch, HBASE-15291-revert-master.patch, > HBASE-15291.001.patch, HBASE-15291.002.patch, HBASE-15291.003.patch, > HBASE-15291.004.patch, HBASE-15291.addendum, HBASE-15291.patch, > HBASE-15291.v1.patch, HBASE-15291.v2.patch, HBASE-15291.v2.patch, patch > > > FileSystem not closed in secure bulkLoad after bulkLoad finish, it will > cause memory used more and more if too many bulkLoad . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-15291) FileSystem not closed in secure bulkLoad
[ https://issues.apache.org/jira/browse/HBASE-15291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Singhi updated HBASE-15291: -- Attachment: HBASE-15291-branch-1.patch > FileSystem not closed in secure bulkLoad > > > Key: HBASE-15291 > URL: https://issues.apache.org/jira/browse/HBASE-15291 > Project: HBase > Issue Type: Bug >Affects Versions: 1.0.2, 0.98.16.1 >Reporter: Yong Zhang >Assignee: Ashish Singhi >Priority: Major > Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1 > > Attachments: HBASE-15291-branch-1.2.patch, > HBASE-15291-branch-1.patch, HBASE-15291-revert-master.patch, > HBASE-15291.001.patch, HBASE-15291.002.patch, HBASE-15291.003.patch, > HBASE-15291.004.patch, HBASE-15291.addendum, HBASE-15291.patch, > HBASE-15291.v1.patch, HBASE-15291.v2.patch, HBASE-15291.v2.patch, patch > > > FileSystem not closed in secure bulkLoad after bulkLoad finish, it will > cause memory used more and more if too many bulkLoad . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-15291) FileSystem not closed in secure bulkLoad
[ https://issues.apache.org/jira/browse/HBASE-15291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Singhi updated HBASE-15291: -- Attachment: HBASE-15291-branch-1.2.patch > FileSystem not closed in secure bulkLoad > > > Key: HBASE-15291 > URL: https://issues.apache.org/jira/browse/HBASE-15291 > Project: HBase > Issue Type: Bug >Affects Versions: 1.0.2, 0.98.16.1 >Reporter: Yong Zhang >Assignee: Ashish Singhi >Priority: Major > Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1 > > Attachments: HBASE-15291-branch-1.2.patch, > HBASE-15291-branch-1.patch, HBASE-15291-revert-master.patch, > HBASE-15291.001.patch, HBASE-15291.002.patch, HBASE-15291.003.patch, > HBASE-15291.004.patch, HBASE-15291.addendum, HBASE-15291.patch, > HBASE-15291.v1.patch, HBASE-15291.v2.patch, HBASE-15291.v2.patch, patch > > > FileSystem not closed in secure bulkLoad after bulkLoad finish, it will > cause memory used more and more if too many bulkLoad . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20068) Hadoopcheck project health check uses default maven repo instead of yetus managed ones
[
https://issues.apache.org/jira/browse/HBASE-20068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433760#comment-16433760
]
Hudson commented on HBASE-20068:
Results for branch branch-2
[build #597 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/597/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/597//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/597//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/597//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Hadoopcheck project health check uses default maven repo instead of yetus
> managed ones
> --
>
> Key: HBASE-20068
> URL: https://issues.apache.org/jira/browse/HBASE-20068
> Project: HBase
> Issue Type: Bug
> Components: community, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20068.0.patch, HBASE-20068.1.patch
>
>
> Recently had a precommit run fail hadoop check for all 3 versions with
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:2.5.2:install (default-install)
> on project hbase-thrift: Failed to install metadata
> org.apache.hbase:hbase-thrift:3.0.0-SNAPSHOT/maven-metadata.xml: Could not
> parse metadata
> /home/jenkins/.m2/repository/org/apache/hbase/hbase-thrift/3.0.0-SNAPSHOT/maven-metadata-local.xml:
> in epilog non whitespace content is not allowed but got / (position: END_TAG
> seen ...\n/... @25:2) -> [Help 1]
> {code}
> Looks like maven repo corruption.
> Also the path {{/home/jenkins/.m2/repository}} means that those invocations
> are using the jenkins user repo, which isn't safe since there are multiple
> executors. either the plugin isn't using the yetus provided maven repo path
> or our yetus invocation isn't telling yetus to provide its own maven repo
> path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20335) nightly jobs no longer contain machine information
[
https://issues.apache.org/jira/browse/HBASE-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433761#comment-16433761
]
Hudson commented on HBASE-20335:
Results for branch branch-2
[build #597 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/597/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/597//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/597//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/597//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> nightly jobs no longer contain machine information
> --
>
> Key: HBASE-20335
> URL: https://issues.apache.org/jira/browse/HBASE-20335
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-20335.0.patch
>
>
> something is up with nightly jobs. they no longer have the machine
> information from HBASE-19228.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20253) Error message is missing for restore_snapshot
[
https://issues.apache.org/jira/browse/HBASE-20253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433567#comment-16433567
]
Hadoop QA commented on HBASE-20253:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
11s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
24s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
8s{color} | {color:red} The patch generated 4 new + 336 unchanged - 34 fixed =
340 total (was 370) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
19s{color} | {color:red} The patch generated 18 new + 548 unchanged - 6 fixed =
566 total (was 554) {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} 0m
10s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 9m
30s{color} | {color:green} hbase-shell 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} 22m 11s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20253 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12918527/HBASE-20253.master.004.patch
|
| Optional Tests | asflicense javac javadoc unit rubocop ruby_lint |
| uname | Linux c88064e3973a 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10
14:24:03 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / a2b9172771 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| rubocop | v0.54.0 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/12389/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.1 |
| ruby-lint |
https://builds.apache.org/job/PreCommit-HBASE-Build/12389/artifact/patchprocess/diff-patch-ruby-lint.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12389/testReport/ |
| Max. process+thread count | 2467 (vs. ulimit of 1) |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12389/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Error message is missing for restore_snapshot
> -
>
> Key: HBASE-20253
> URL: https://issues.apache.org/jira/browse/HBASE-20253
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Minor
> Attachments: HBASE-20253.master.001.patch,
> HBASE-20253.master.002.patch, HBASE-20253.master.003.patch,
> HBASE-20253.master.004.patch
>
>
> When the table is not disabled and restore_snapshot executed the error
> message is useless, only displays the table name.
> hbase(main):007:0> restore_snapshot 'tsnap'
> ERROR: t
> Restore a specified snapshot.
> The restore will replace the content of the original table,
> bringing back the content to the snapshot state.
> The table must be disabled.
> Examples:
> hbase> restore_snapshot 'snapshotName'
> Following command will restore all acl from snapshot table into the table.
> hbase>
[jira] [Commented] (HBASE-20219) An error occurs when scanning with reversed=true and loadColumnFamiliesOnDemand=true
[
https://issues.apache.org/jira/browse/HBASE-20219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433613#comment-16433613
]
Hadoop QA commented on HBASE-20219:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
14s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
22s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
56s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
6s{color} | {color:green} hbase-server: The patch generated 0 new + 5
unchanged - 4 fixed = 5 total (was 9) {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
46s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 4s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
41s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}124m
59s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}170m 53s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20219 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12917493/HBASE-20219.master.004.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux f9a4ab2799b4 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 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 / a2c1be9a76 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12387/testReport/ |
| Max. process+thread count | 4866 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12387/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This
[jira] [Commented] (HBASE-20358) Fix bin/hbase thrift usage text
[
https://issues.apache.org/jira/browse/HBASE-20358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433697#comment-16433697
]
Peter Somogyi commented on HBASE-20358:
---
lgtm.
[~stack], how about pushing this to branch-2.0?
> Fix bin/hbase thrift usage text
> ---
>
> Key: HBASE-20358
> URL: https://issues.apache.org/jira/browse/HBASE-20358
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0-beta-2
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-20358.branch-2.0.001.patch
>
>
> 1. Thrift server usage text does not say anything about it requires a
> {{start}} or {{stop}} argument.
> 2. It ignores {{stop}} argument, it acts as the same as for {{start}}.
> According to this comment:
> {code:java}
> // This is so complicated to please both bin/hbase and bin/hbase-daemon.
> // hbase-daemon provides "start" and "stop" arguments
> // hbase should print the help if no argument is provided
> {code}
> {{start}} and {{stop}} is just supported because {{bin/hbase-daemon}}, but
> hbase-daemon kills the process instead of calling it with a {{stop}} argument.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20128) Add new UTs which extends the old replication UTs but set replication scope to SERIAL
[ https://issues.apache.org/jira/browse/HBASE-20128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433695#comment-16433695 ] Zheng Hu commented on HBASE-20128: -- Checked the code again, the previous parameterized member serialPeer does not work, which means all UTs are running in non-serial peer in actually. So I modified the patch , and Hadoop QA again, to see if UT fail for serial peer . > Add new UTs which extends the old replication UTs but set replication scope > to SERIAL > - > > Key: HBASE-20128 > URL: https://issues.apache.org/jira/browse/HBASE-20128 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-20128.v1.patch, HBASE-20128.v2.patch, > HBASE-20128.v3.patch, HBASE-20128.v3.patch > > > Make sure that the basic function for replicationstill works. The serial > replication UTs are focused on order. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20188) [TESTING] Performance
[ https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433710#comment-16433710 ] Eshcar Hillel commented on HBASE-20188: --- And another thing, might be just a distraction but we think it is worth mentioning – Backward scans should run faster with IMC since the flat segments are simply arrays and it is very simple to go to prev in O(1), while in skip list prev is implemented by seeking the prev key which is done in O(log n). We don't have an easy way to verify this since YCSB does not support testing this kind of operation, but we are looking into it and will report if something interesting comes up. > [TESTING] Performance > - > > Key: HBASE-20188 > URL: https://issues.apache.org/jira/browse/HBASE-20188 > Project: HBase > Issue Type: Umbrella > Components: Performance >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 2.0.0 > > Attachments: CAM-CONFIG-V01.patch, HBASE-20188-xac.sh, > HBASE-20188.sh, HBase 2.0 performance evaluation - 8GB(1).pdf, HBase 2.0 > performance evaluation - 8GB.pdf, HBase 2.0 performance evaluation - Basic vs > None_ system settings.pdf, ITBLL2.5B_1.2.7vs2.0.0_cpu.png, > ITBLL2.5B_1.2.7vs2.0.0_gctime.png, ITBLL2.5B_1.2.7vs2.0.0_iops.png, > ITBLL2.5B_1.2.7vs2.0.0_load.png, ITBLL2.5B_1.2.7vs2.0.0_memheap.png, > ITBLL2.5B_1.2.7vs2.0.0_memstore.png, ITBLL2.5B_1.2.7vs2.0.0_ops.png, > ITBLL2.5B_1.2.7vs2.0.0_ops_NOT_summing_regions.png, YCSB_CPU.png, > YCSB_GC_TIME.png, YCSB_IN_MEMORY_COMPACTION=NONE.ops.png, YCSB_MEMSTORE.png, > YCSB_OPs.png, YCSB_in-memory-compaction=NONE.ops.png, YCSB_load.png, > flamegraph-1072.1.svg, flamegraph-1072.2.svg, hbase-env.sh, hbase-site.xml, > hbase-site.xml, lock.127.workloadc.20180402T200918Z.svg, > lock.2.memsize2.c.20180403T160257Z.svg, run_ycsb.sh, tree.txt, workloadx, > workloadx > > > How does 2.0.0 compare to old versions? Is it faster, slower? There is rumor > that it is much slower, that the problem is the asyncwal writing. Does > in-memory compaction slow us down or speed us up? What happens when you > enable offheaping? > Keep notes here in this umbrella issue. Need to be able to say something > about perf when 2.0.0 ships. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20128) Add new UTs which extends the old replication UTs but set replication scope to SERIAL
[ https://issues.apache.org/jira/browse/HBASE-20128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-20128: - Attachment: HBASE-20128.v4.patch > Add new UTs which extends the old replication UTs but set replication scope > to SERIAL > - > > Key: HBASE-20128 > URL: https://issues.apache.org/jira/browse/HBASE-20128 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-20128.v1.patch, HBASE-20128.v2.patch, > HBASE-20128.v3.patch, HBASE-20128.v3.patch, HBASE-20128.v4.patch > > > Make sure that the basic function for replicationstill works. The serial > replication UTs are focused on order. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20386) [DOC] Align WALPlayer help text and refguide
[
https://issues.apache.org/jira/browse/HBASE-20386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433836#comment-16433836
]
Hadoop QA commented on HBASE-20386:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
14s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
30s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
35s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 3m
43s{color} | {color:blue} branch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
45s{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: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
26s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {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} 4m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m
21s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
16s{color} | {color:red} hbase-mapreduce: The patch generated 1 new + 1
unchanged - 0 fixed = 2 total (was 1) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 2m
12s{color} | {color:red} root: The patch generated 1 new + 1 unchanged - 0
fixed = 2 total (was 1) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 3m
20s{color} | {color:blue} patch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
36s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 19s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
9s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}185m
47s{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
[jira] [Commented] (HBASE-20151) Bug with SingleColumnValueFilter and FamilyFilter
[
https://issues.apache.org/jira/browse/HBASE-20151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433912#comment-16433912
]
Hadoop QA commented on HBASE-20151:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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
1s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
22s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
50s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
50s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
33s{color} | {color:green} hbase-client: The patch generated 0 new + 154
unchanged - 1 fixed = 154 total (was 155) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
14s{color} | {color:green} The patch hbase-server passed checkstyle {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
57s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 9s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
2s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}108m
41s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
39s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}164m 17s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20151 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12918540/HBASE-20151.master.003.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 97f4b861eee5 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Updated] (HBASE-20377) Deal with table in enabling and disabling state when modifying serial replication peer
[ https://issues.apache.org/jira/browse/HBASE-20377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20377: -- Assignee: Duo Zhang Fix Version/s: 2.1.0 3.0.0 Status: Patch Available (was: Open) > Deal with table in enabling and disabling state when modifying serial > replication peer > -- > > Key: HBASE-20377 > URL: https://issues.apache.org/jira/browse/HBASE-20377 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.1.0 > > Attachments: HBASE-20377.patch > > > There could be race between reopening regions and enabling table, and also > between disabling table and write last pushed sequence id for disabled table. > Maybe we need to wait for the table state to become enabled or disabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19761) Fix Checkstyle errors in hbase-zookeeper
[ https://issues.apache.org/jira/browse/HBASE-19761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-19761: Status: In Progress (was: Patch Available) moving out of patch available pending update for review feedback. (the hadoop check failures were probably unrelated. we've recently fixed an issue that caused flakiness in that build process) > Fix Checkstyle errors in hbase-zookeeper > > > Key: HBASE-19761 > URL: https://issues.apache.org/jira/browse/HBASE-19761 > Project: HBase > Issue Type: Sub-task >Reporter: Jan Hentschel >Assignee: maoling >Priority: Minor > Attachments: HBASE-19761-master-v0.patch > > > Fix the remaining Checkstyle errors in the *hbase-zookeeper* module and > enable Checkstyle to fail on violations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20294) Also cleanup last pushed sequence id in ReplicationBarrierCleaner
[ https://issues.apache.org/jira/browse/HBASE-20294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20294: -- Assignee: Duo Zhang Status: Patch Available (was: Open) > Also cleanup last pushed sequence id in ReplicationBarrierCleaner > - > > Key: HBASE-20294 > URL: https://issues.apache.org/jira/browse/HBASE-20294 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20294.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20163) Forbid major compaction when standby cluster replay the remote wals
[ https://issues.apache.org/jira/browse/HBASE-20163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433830#comment-16433830 ] Duo Zhang commented on HBASE-20163: --- Is it safe to only disable major compaction? Do we also purge delete markers if a minor compaction is for all the store files? > Forbid major compaction when standby cluster replay the remote wals > --- > > Key: HBASE-20163 > URL: https://issues.apache.org/jira/browse/HBASE-20163 > Project: HBase > Issue Type: Sub-task >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-20163.HBASE-19064.001.patch, > HBASE-20163.HBASE-19064.002.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20294) Also cleanup last pushed sequence id in ReplicationBarrierCleaner
[ https://issues.apache.org/jira/browse/HBASE-20294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20294: -- Attachment: HBASE-20294.patch > Also cleanup last pushed sequence id in ReplicationBarrierCleaner > - > > Key: HBASE-20294 > URL: https://issues.apache.org/jira/browse/HBASE-20294 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20294.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20335) nightly jobs no longer contain machine information
[ https://issues.apache.org/jira/browse/HBASE-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433980#comment-16433980 ] Sean Busbey commented on HBASE-20335: - okay that wasn't it, since the nightly jobs do not have machine info still. maybe it's a missing archival step. I'll try that next. > nightly jobs no longer contain machine information > -- > > Key: HBASE-20335 > URL: https://issues.apache.org/jira/browse/HBASE-20335 > Project: HBase > Issue Type: Bug > Components: test >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Attachments: HBASE-20335.0.patch > > > something is up with nightly jobs. they no longer have the machine > information from HBASE-19228. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-18620) Secure bulkload job fails when HDFS umask has limited scope
[
https://issues.apache.org/jira/browse/HBASE-18620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433817#comment-16433817
]
Pankaj Kumar commented on HBASE-18620:
--
TestGlobalThrottler failure is not relevant.
> Secure bulkload job fails when HDFS umask has limited scope
> ---
>
> Key: HBASE-18620
> URL: https://issues.apache.org/jira/browse/HBASE-18620
> Project: HBase
> Issue Type: Bug
> Components: security
>Reporter: Pankaj Kumar
>Assignee: Pankaj Kumar
>Priority: Major
> Fix For: 1.5.0
>
> Attachments: HBASE-18620-branch-1-v2.patch, HBASE-18620-branch-1.patch
>
>
> By default "hbase.fs.tmp.dir" parameter value is
> /user/$\{user.name}/hbase-staging.
> RegionServer creates the staging directory (hbase.bulkload.staging.dir,
> default value is hbase.fs.tmp.dir) during opening a region as below when
> SecureBulkLoadEndpoint configured in hbase.coprocessor.region.classes,
> {noformat}
> drwx-- - hbase hadoop 0 2017-08-12 13:55 /user/xyz
> drwx--x--x - hbase hadoop 0 2017-08-12 13:55 /user/xyz/hbase-staging
> drwx--x--x - hbase hadoop 0 2017-08-12 13:55
> /user/xyz/hbase-staging/DONOTERASE
> {noformat}
> Here,
> 1. RegionServer is started using "xyz" linux user.
> 2. HDFS umask (fs.permissions.umask-mode) has been set as 077, so file/dir
> permission will not be wider than 700. "/user/xyz" directory (doesn't exist
> earlier) permission will be 700 and "/user/xyz/hbase-staging" will be 711 as
> we are just setting permission of staging directory not the parent
> directories which are created (fs.mkdirs()) by RegionServer.
> Secure bulkload will fail as other user doesn't have EXECUTE permission on
> "/user/xyz" directory.
> *Steps to reproduce:*
> ==
> 1. Configure org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint
> in "hbase.coprocessor.region.classes" at client side.
> 2. Login to machine as "root" linux user.
> 3. kinit to any kerberos user except RegionServer kerberos user (say admin).
> 4. ImportTSV will create the user temp directory (hbase.fs.tmp.dir) while
> writing partition file,
> {noformat}
> drwxrwxrwx - admin hadoop 0 2017-08-12 14:52 /user/root
> drwxrwxrwx - admin hadoop 0 2017-08-12 14:52 /user/root/hbase-staging
> {noformat}
> 4. During LoadIncrementalHFiles job,
> - a. prepareBulkLoad() step - Random dir will be created by RegionServer
> credentials,
> {noformat}
> drwxrwxrwx - hbase hadoop 0 2017-08-12 14:58
> /user/xyz/hbase-staging/hbase__t1__e67b23m2ghe6fkn1bqrb95ak41ferj8957cdhsep4ebmpohm22nvi54vh8g3qh1
> {noformat}
> - b. secureBulkLoadHFiles() step - Family dir existence check and creation is
> done by using client user credentials. Here client operation will fail as
> below,
> {noformat}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
> Permission denied: user=admin, access=EXECUTE,
> inode="/user/xyz/hbase-staging/admin__t1__e1f3m4r2prud9117thg5pdg91lkg0le0fdvtbbpg03epqg0f14lv54j8sqd8s0n6/cf1":hbase:hadoop:drwx--
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:342)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkTraverse(FSPermissionChecker.java:279)
> at
> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:223)
> at
> com.huawei.hadoop.adapter.hdfs.plugin.HWAccessControlEnforce.checkPermission(HWAccessControlEnforce.java:69)
> {noformat}
> So the root cause is "admin" user doesn't have EXECUTE permission over
> "/user/xyz", because RegionServer has created this intermediate parent
> directory during opening (SecureBulkLoadEndpoint) a region where the default
> permission is set as 700 based on the hdfs UMASK 077.
> *Solution:*
> =
> However it can be handled by the creating /user/xyz manually and setting
> sufficient permission explicitly. But we should handle this by setting
> sufficient permission to intermediate staging directories which is created by
> RegionServer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20368) Fix RIT stuck when a rsgroup has no online servers but AM's pendingAssginQueue is cleared
[
https://issues.apache.org/jira/browse/HBASE-20368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433930#comment-16433930
]
Hadoop QA commented on HBASE-20368:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
14s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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:brown} branch-2.0 Compile Tests {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} 3m
20s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
58s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
6s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
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} 2m
19s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
40s{color} | {color:green} branch-2.0 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
12s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
0s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
10s{color} | {color:red} hbase-rsgroup: The patch generated 2 new + 0 unchanged
- 0 fixed = 2 total (was 0) {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
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}
10m 35s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}107m
56s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 53s{color}
| {color:red} hbase-rsgroup in the patch failed. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m
39s{color} | {color:red} The patch generated 2 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}147m 51s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.rsgroup.TestAssignmentOnRSGroupCrash |
| | hadoop.hbase.rsgroup.TestRSGroupsWithACL |
| | hadoop.hbase.rsgroup.TestRSGroups |
| | hadoop.hbase.rsgroup.TestRSGroupsOfflineMode |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:369877d |
| JIRA Issue | HBASE-20368 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12918544/HBASE-20368.branch-2.0.003.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 8ef534d4ff90 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 GNU/Linux |
| Build tool | maven
[jira] [Commented] (HBASE-20377) Deal with table in enabling and disabling state when modifying serial replication peer
[ https://issues.apache.org/jira/browse/HBASE-20377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433965#comment-16433965 ] Duo Zhang commented on HBASE-20377: --- Review board link: https://reviews.apache.org/r/66551/ > Deal with table in enabling and disabling state when modifying serial > replication peer > -- > > Key: HBASE-20377 > URL: https://issues.apache.org/jira/browse/HBASE-20377 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.1.0 > > Attachments: HBASE-20377.patch > > > There could be race between reopening regions and enabling table, and also > between disabling table and write last pushed sequence id for disabled table. > Maybe we need to wait for the table state to become enabled or disabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20367) Write a replication barrier for regions when disabling a table
[ https://issues.apache.org/jira/browse/HBASE-20367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433825#comment-16433825 ] Zheng Hu commented on HBASE-20367: -- +1 > Write a replication barrier for regions when disabling a table > -- > > Key: HBASE-20367 > URL: https://issues.apache.org/jira/browse/HBASE-20367 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.1.0 > > Attachments: HBASE-20367.patch > > > So that we can use the same algorithm for split/merged regions to remove the > barriers when replication is done. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20382) If RSGroups not enabled, rsgroup.jsp prints stack trace
[
https://issues.apache.org/jira/browse/HBASE-20382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balazs Meszaros updated HBASE-20382:
Status: Patch Available (was: Open)
> If RSGroups not enabled, rsgroup.jsp prints stack trace
> ---
>
> Key: HBASE-20382
> URL: https://issues.apache.org/jira/browse/HBASE-20382
> Project: HBase
> Issue Type: Bug
> Components: rsgroup, UI
>Reporter: Mike Drob
>Assignee: Balazs Meszaros
>Priority: Major
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-20382.branch-2.0.001.patch
>
>
> Going to {{rsgroup.jsp?name=foo}} I get the following stack trace:
> {noformat}
> org.apache.hadoop.hbase.TableNotFoundException: hbase:rsgroup
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegionInMeta(ConnectionImplementation.java:842)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:733)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:719)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:690)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.getRegionLocation(ConnectionImplementation.java:571)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.getRegionLocation(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.HRegionLocator.getRegionLocation(HRegionLocator.java:73)
> at
> org.apache.hadoop.hbase.client.RegionServerCallable.prepare(RegionServerCallable.java:223)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCallerImpl.callWithRetries(RpcRetryingCallerImpl.java:105)
> at org.apache.hadoop.hbase.client.HTable.get(HTable.java:385)
> at org.apache.hadoop.hbase.client.HTable.get(HTable.java:359)
> at
> org.apache.hadoop.hbase.RSGroupTableAccessor.getRSGroupInfo(RSGroupTableAccessor.java:75)
> at
> org.apache.hadoop.hbase.generated.master.rsgroup_jsp._jspService(rsgroup_jsp.java:78)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:840)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1772)
> at
> org.apache.hadoop.hbase.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:112)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.ClickjackingPreventionFilter.doFilter(ClickjackingPreventionFilter.java:48)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:1374)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.NoCacheFilter.doFilter(NoCacheFilter.java:49)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.NoCacheFilter.doFilter(NoCacheFilter.java:49)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
>
[jira] [Updated] (HBASE-20377) Deal with table in enabling and disabling state when modifying serial replication peer
[ https://issues.apache.org/jira/browse/HBASE-20377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20377: -- Attachment: HBASE-20377.patch > Deal with table in enabling and disabling state when modifying serial > replication peer > -- > > Key: HBASE-20377 > URL: https://issues.apache.org/jira/browse/HBASE-20377 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.1.0 > > Attachments: HBASE-20377.patch > > > There could be race between reopening regions and enabling table, and also > between disabling table and write last pushed sequence id for disabled table. > Maybe we need to wait for the table state to become enabled or disabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20367) Write a replication barrier for regions when disabling a table
[ https://issues.apache.org/jira/browse/HBASE-20367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20367: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to master and branch-2. Thanks [~openinx] for reviewing. > Write a replication barrier for regions when disabling a table > -- > > Key: HBASE-20367 > URL: https://issues.apache.org/jira/browse/HBASE-20367 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.1.0 > > Attachments: HBASE-20367.patch > > > So that we can use the same algorithm for split/merged regions to remove the > barriers when replication is done. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20368) Fix RIT stuck when a rsgroup has no online servers but AM's pendingAssginQueue is cleared
[
https://issues.apache.org/jira/browse/HBASE-20368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433891#comment-16433891
]
Hadoop QA commented on HBASE-20368:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
14s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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:brown} branch-2.0 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
8s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
59s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
7s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
35s{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
17s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
42s{color} | {color:green} branch-2.0 passed {color} |
|| || || || {color:brown} Patch Compile Tests {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} 3m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
0s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
11s{color} | {color:red} hbase-rsgroup: The patch generated 2 new + 0 unchanged
- 0 fixed = 2 total (was 0) {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
35s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 55s{color} | {color:green} Patch does not cause any errors with Hadoop 2.6.5
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
38s{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:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}104m
24s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 51s{color}
| {color:red} hbase-rsgroup in the patch failed. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m
25s{color} | {color:red} The patch generated 2 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}142m 45s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.rsgroup.TestAssignmentOnRSGroupCrash |
| | hadoop.hbase.rsgroup.TestRSGroupsWithACL |
| | hadoop.hbase.rsgroup.TestRSGroups |
| | hadoop.hbase.rsgroup.TestRSGroupsOfflineMode |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:dba4808 |
| JIRA Issue | HBASE-20368 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12918543/HBASE-20368.branch-2.0.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 613e5c87021c 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 GNU/Linux |
| Build tool | maven
[jira] [Updated] (HBASE-20382) If RSGroups not enabled, rsgroup.jsp prints stack trace
[
https://issues.apache.org/jira/browse/HBASE-20382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balazs Meszaros updated HBASE-20382:
Attachment: HBASE-20382.branch-2.0.001.patch
> If RSGroups not enabled, rsgroup.jsp prints stack trace
> ---
>
> Key: HBASE-20382
> URL: https://issues.apache.org/jira/browse/HBASE-20382
> Project: HBase
> Issue Type: Bug
> Components: rsgroup, UI
>Reporter: Mike Drob
>Assignee: Balazs Meszaros
>Priority: Major
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-20382.branch-2.0.001.patch
>
>
> Going to {{rsgroup.jsp?name=foo}} I get the following stack trace:
> {noformat}
> org.apache.hadoop.hbase.TableNotFoundException: hbase:rsgroup
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegionInMeta(ConnectionImplementation.java:842)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:733)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:719)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:690)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.getRegionLocation(ConnectionImplementation.java:571)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.getRegionLocation(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.HRegionLocator.getRegionLocation(HRegionLocator.java:73)
> at
> org.apache.hadoop.hbase.client.RegionServerCallable.prepare(RegionServerCallable.java:223)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCallerImpl.callWithRetries(RpcRetryingCallerImpl.java:105)
> at org.apache.hadoop.hbase.client.HTable.get(HTable.java:385)
> at org.apache.hadoop.hbase.client.HTable.get(HTable.java:359)
> at
> org.apache.hadoop.hbase.RSGroupTableAccessor.getRSGroupInfo(RSGroupTableAccessor.java:75)
> at
> org.apache.hadoop.hbase.generated.master.rsgroup_jsp._jspService(rsgroup_jsp.java:78)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:840)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1772)
> at
> org.apache.hadoop.hbase.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:112)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.ClickjackingPreventionFilter.doFilter(ClickjackingPreventionFilter.java:48)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:1374)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.NoCacheFilter.doFilter(NoCacheFilter.java:49)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.NoCacheFilter.doFilter(NoCacheFilter.java:49)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
>
[jira] [Commented] (HBASE-20128) Add new UTs which extends the old replication UTs but set replication scope to SERIAL
[
https://issues.apache.org/jira/browse/HBASE-20128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434010#comment-16434010
]
Hadoop QA commented on HBASE-20128:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
31s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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 13 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
18s{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
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
35s{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} 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
20s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
13m 7s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}163m 42s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
23s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}205m 20s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.replication.multiwal.TestReplicationEndpointWithMultipleWAL |
| | hadoop.hbase.replication.TestReplicationKillMasterRSCompressed |
| | hadoop.hbase.replication.TestReplicationSyncUpTool |
| |
hadoop.hbase.replication.multiwal.TestReplicationKillMasterRSCompressedWithMultipleWAL
|
| |
hadoop.hbase.replication.multiwal.TestReplicationSyncUpToolWithMultipleWAL |
| |
hadoop.hbase.replication.multiwal.TestReplicationEndpointWithMultipleAsyncWAL |
| |
hadoop.hbase.replication.multiwal.TestReplicationKillMasterRSCompressedWithMultipleAsyncWAL
|
| | hadoop.hbase.replication.TestReplicationEndpoint |
| |
hadoop.hbase.replication.multiwal.TestReplicationSyncUpToolWithMultipleAsyncWAL
|
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20128 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12918545/HBASE-20128.v4.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 423179c54e85 4.4.0-89-generic #112-Ubuntu SMP Mon Jul 31
19:38:41 UTC 2017 x86_64 GNU/Linux |
| Build
[jira] [Commented] (HBASE-20243) [Shell] Add shell command to create a new table by cloning the existent table
[ https://issues.apache.org/jira/browse/HBASE-20243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434043#comment-16434043 ] Sean Busbey commented on HBASE-20243: - +1 thanks for the prompt update! > [Shell] Add shell command to create a new table by cloning the existent table > - > > Key: HBASE-20243 > URL: https://issues.apache.org/jira/browse/HBASE-20243 > Project: HBase > Issue Type: Improvement > Components: shell >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Minor > Fix For: 2.1.0 > > Attachments: HBASE-20243.master.001.patch, > HBASE-20243.master.002.patch, HBASE-20243.master.003.patch, > HBASE-20243.master.004.patch, HBASE-20243.master.005.patch, > HBASE-20243.master.006.patch, HBASE-20243.master.007.patch, > HBASE-20243.master.008.patch, HBASE-20243.master.008.patch, > HBASE-20243.master.009.patch, HBASE-20243.master.010.patch > > > In the production environment, we need to create a new table every day. The > schema and the split keys of the table are the same as that of yesterday's > table, only the name of the table is different. For example, > x_20180321,x_20180322 etc.But now there is no convenient command to > do this. So we may need such a command(clone_table) to create a new table by > cloning the existent table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20243) [Shell] Add shell command to create a new table by cloning the existent table
[ https://issues.apache.org/jira/browse/HBASE-20243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434048#comment-16434048 ] Ted Yu commented on HBASE-20243: +1 > [Shell] Add shell command to create a new table by cloning the existent table > - > > Key: HBASE-20243 > URL: https://issues.apache.org/jira/browse/HBASE-20243 > Project: HBase > Issue Type: Improvement > Components: shell >Reporter: Guangxu Cheng >Assignee: Guangxu Cheng >Priority: Minor > Fix For: 2.1.0 > > Attachments: HBASE-20243.master.001.patch, > HBASE-20243.master.002.patch, HBASE-20243.master.003.patch, > HBASE-20243.master.004.patch, HBASE-20243.master.005.patch, > HBASE-20243.master.006.patch, HBASE-20243.master.007.patch, > HBASE-20243.master.008.patch, HBASE-20243.master.008.patch, > HBASE-20243.master.009.patch, HBASE-20243.master.010.patch > > > In the production environment, we need to create a new table every day. The > schema and the split keys of the table are the same as that of yesterday's > table, only the name of the table is different. For example, > x_20180321,x_20180322 etc.But now there is no convenient command to > do this. So we may need such a command(clone_table) to create a new table by > cloning the existent table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20253) Error message is missing for restore_snapshot
[
https://issues.apache.org/jira/browse/HBASE-20253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi updated HBASE-20253:
--
Resolution: Fixed
Fix Version/s: 2.0.0
2.1.0
3.0.0
Status: Resolved (was: Patch Available)
Pushed to branch-2.0+.
> Error message is missing for restore_snapshot
> -
>
> Key: HBASE-20253
> URL: https://issues.apache.org/jira/browse/HBASE-20253
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Minor
> Fix For: 3.0.0, 2.1.0, 2.0.0
>
> Attachments: HBASE-20253.master.001.patch,
> HBASE-20253.master.002.patch, HBASE-20253.master.003.patch,
> HBASE-20253.master.004.patch
>
>
> When the table is not disabled and restore_snapshot executed the error
> message is useless, only displays the table name.
> hbase(main):007:0> restore_snapshot 'tsnap'
> ERROR: t
> Restore a specified snapshot.
> The restore will replace the content of the original table,
> bringing back the content to the snapshot state.
> The table must be disabled.
> Examples:
> hbase> restore_snapshot 'snapshotName'
> Following command will restore all acl from snapshot table into the table.
> hbase> restore_snapshot 'snapshotName', \{RESTORE_ACL=>true}
> Took 0.1044 seconds
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20335) nightly jobs no longer contain machine information
[
https://issues.apache.org/jira/browse/HBASE-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434094#comment-16434094
]
Hudson commented on HBASE-20335:
Results for branch HBASE-20355
[build #1 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-20355/1/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-20355/1//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-20355/1//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-20355/1//JDK8_Nightly_Build_Report_(Hadoop3)/]
> nightly jobs no longer contain machine information
> --
>
> Key: HBASE-20335
> URL: https://issues.apache.org/jira/browse/HBASE-20335
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-20335.0.patch
>
>
> something is up with nightly jobs. they no longer have the machine
> information from HBASE-19228.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20385) Purge md5-making from our little make_rc.sh script
[ https://issues.apache.org/jira/browse/HBASE-20385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434131#comment-16434131 ] stack commented on HBASE-20385: --- Thanks [~elserj] > Purge md5-making from our little make_rc.sh script > -- > > Key: HBASE-20385 > URL: https://issues.apache.org/jira/browse/HBASE-20385 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-20385.master.001.patch > > > Don't generate md5s anymore. New Apache release policy via Apache > Infrastructure asks that we not provide md5 as md5 is 'broken for many > purposes; we should movea awy from it.' Remove the md5' making from our > make-rc.sh script. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20382) If RSGroups not enabled, rsgroup.jsp prints stack trace
[
https://issues.apache.org/jira/browse/HBASE-20382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434209#comment-16434209
]
Hadoop QA commented on HBASE-20382:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} branch-2.0 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
2s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
39s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
20s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
41s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
18s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
6s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
55s{color} | {color:green} branch-2.0 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
46s{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
16s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
11m 35s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
6s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}121m
8s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
46s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}173m 4s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:369877d |
| JIRA Issue | HBASE-20382 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12918569/HBASE-20382.branch-2.0.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 368157ac54c8 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 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.0 /
[jira] [Updated] (HBASE-17554) Figure 2.0.0 Hadoop Version Support; update refguide
[ https://issues.apache.org/jira/browse/HBASE-17554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17554: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to master Will copy back before next RC. Thanks [~mdrob] > Figure 2.0.0 Hadoop Version Support; update refguide > > > Key: HBASE-17554 > URL: https://issues.apache.org/jira/browse/HBASE-17554 > Project: HBase > Issue Type: Sub-task > Components: documentation >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-17554.master.001.patch > > > Refguide has hbase-2.0.0 working with 2.6.1+ and 2.7.1+ but I just tried tip > of master against hadoop-2.7.3 and it fails with a netty version complaint > (same as up in HADOOP-13866 which is trying to update netty for hadoop3 and > 2.9?). This issue is about determining proper hadoop versions we work with > when hbase2 ships. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20386) [DOC] Align WALPlayer help text and refguide
[ https://issues.apache.org/jira/browse/HBASE-20386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20386: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: (was: 3.0.0) 2.0.0 Status: Resolved (was: Patch Available) Pushed to branch-2.0+. Pushed the doc change to master only. Will copy it back before I make next RC. Thanks for the nice fixup to important tool [~balazs.meszaros] > [DOC] Align WALPlayer help text and refguide > > > Key: HBASE-20386 > URL: https://issues.apache.org/jira/browse/HBASE-20386 > Project: HBase > Issue Type: Task > Components: documentation >Affects Versions: 2.0.0 >Reporter: Balazs Meszaros >Assignee: Balazs Meszaros >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-20386.master.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20382) If RSGroups not enabled, rsgroup.jsp prints stack trace
[
https://issues.apache.org/jira/browse/HBASE-20382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434206#comment-16434206
]
stack commented on HBASE-20382:
---
Tried backporting to branch-1 but doesn't apply.
> If RSGroups not enabled, rsgroup.jsp prints stack trace
> ---
>
> Key: HBASE-20382
> URL: https://issues.apache.org/jira/browse/HBASE-20382
> Project: HBase
> Issue Type: Bug
> Components: rsgroup, UI
>Reporter: Mike Drob
>Assignee: Balazs Meszaros
>Priority: Major
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-20382.branch-2.0.001.patch
>
>
> Going to {{rsgroup.jsp?name=foo}} I get the following stack trace:
> {noformat}
> org.apache.hadoop.hbase.TableNotFoundException: hbase:rsgroup
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegionInMeta(ConnectionImplementation.java:842)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:733)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:719)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.locateRegion(ConnectionImplementation.java:690)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.locateRegion(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.getRegionLocation(ConnectionImplementation.java:571)
> at
> org.apache.hadoop.hbase.client.ConnectionUtils$ShortCircuitingClusterConnection.getRegionLocation(ConnectionUtils.java:131)
> at
> org.apache.hadoop.hbase.client.HRegionLocator.getRegionLocation(HRegionLocator.java:73)
> at
> org.apache.hadoop.hbase.client.RegionServerCallable.prepare(RegionServerCallable.java:223)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCallerImpl.callWithRetries(RpcRetryingCallerImpl.java:105)
> at org.apache.hadoop.hbase.client.HTable.get(HTable.java:385)
> at org.apache.hadoop.hbase.client.HTable.get(HTable.java:359)
> at
> org.apache.hadoop.hbase.RSGroupTableAccessor.getRSGroupInfo(RSGroupTableAccessor.java:75)
> at
> org.apache.hadoop.hbase.generated.master.rsgroup_jsp._jspService(rsgroup_jsp.java:78)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:840)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1772)
> at
> org.apache.hadoop.hbase.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:112)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.ClickjackingPreventionFilter.doFilter(ClickjackingPreventionFilter.java:48)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:1374)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.NoCacheFilter.doFilter(NoCacheFilter.java:49)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.apache.hadoop.hbase.http.NoCacheFilter.doFilter(NoCacheFilter.java:49)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1759)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
>
[jira] [Updated] (HBASE-19963) TestFSHDFSUtils assumes wrong default port for Hadoop 3.0.1+
[
https://issues.apache.org/jira/browse/HBASE-19963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang updated HBASE-19963:
Attachment: HBASE-19963.master.002.patch
> TestFSHDFSUtils assumes wrong default port for Hadoop 3.0.1+
>
>
> Key: HBASE-19963
> URL: https://issues.apache.org/jira/browse/HBASE-19963
> Project: HBase
> Issue Type: Task
> Components: test
>Reporter: Mike Drob
>Assignee: Wei-Chiu Chuang
>Priority: Major
> Attachments: HBASE-19963.master.001.patch,
> HBASE-19963.master.002.patch
>
>
> We try to accommodate HDFS changing ports when testing if it is the same FS
> in our tests:
> https://github.com/apache/hbase/blob/master/hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestFSHDFSUtils.java#L156-L162
> {code}
> if (isHadoop3) {
> // Hadoop 3.0.0 alpha1+ change default nn port to 9820. See HDFS-9427
> testIsSameHdfs(9820);
> } else {
> // pre hadoop 3.0.0 defaults to port 8020
> testIsSameHdfs(8020);
> }
> {code}
> But in Hadoop 3.0.1, they decided to go back to the old port - see HDFS-12990.
> So our tests will fail against the snapshot and against future releases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HBASE-20384) [AMv2] Logging format improvements; use encoded name rather than full region name marking transitions
[ https://issues.apache.org/jira/browse/HBASE-20384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-20384. --- Resolution: Fixed Assignee: stack Hadoop Flags: Reviewed Fix Version/s: 2.0.0 Pushed to branch-2.0+. Thanks [~balazs.meszaros] > [AMv2] Logging format improvements; use encoded name rather than full region > name marking transitions > -- > > Key: HBASE-20384 > URL: https://issues.apache.org/jira/browse/HBASE-20384 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-20384.branch-2.0.001.patch > > > We use encoded name near everywhere. Makes logging regular-looking at least > and eases tracing. In a few places we still do full region name. Let me fix > (ran into it trying to debug...) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20151) Bug with SingleColumnValueFilter and FamilyFilter
[
https://issues.apache.org/jira/browse/HBASE-20151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434102#comment-16434102
]
Ted Yu commented on HBASE-20151:
{code}
+if (logic == FilterListBase.LOGIG.AND &&
{code}
Typo: LOGIG
{code}
+ * @param logic Logic.AND or Logic.AND
{code}
Logic.OR should be mentioned.
Can you add test corresponding to Steven's case ?
thanks
> Bug with SingleColumnValueFilter and FamilyFilter
> -
>
> Key: HBASE-20151
> URL: https://issues.apache.org/jira/browse/HBASE-20151
> Project: HBase
> Issue Type: Bug
> Environment: MacOS 10.13.3
> HBase 1.3.1
>Reporter: Steven Sadowski
>Assignee: Reid Chan
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20151.master.001.patch,
> HBASE-20151.master.002.patch, HBASE-20151.master.003.patch
>
>
> When running the following queries, the result is sometimes return correctly
> and other times incorrectly based on the qualifier queried.
> Setup:
> {code:java}
> create 'test', 'a', 'b'
> test = get_table 'test'
> test.put '1', 'a:1', nil
> test.put '1', 'a:10', nil
> test.put '1', 'b:2', nil
> {code}
>
> This query works fine when the SCVF's qualifier has length 1 (i.e. '1') :
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','1',=,'binary:',true,true) AND
> FamilyFilter(=,'binary:b') )"})
> ROW COLUMN+CELL
> 1column=b:2,
> timestamp=1520455888059, value=
> 1 row(s) in 0.0060 seconds
> {code}
>
> The query should return the same result when passed a qualifier of length 2
> (i.e. '10') :
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','10',=,'binary:',true,true) AND
> FamilyFilter(=,'binary:b') )"})
> ROW COLUMN+CELL
> 0 row(s) in 0.0110 seconds
> {code}
> However, in this case, it does not return any row (expected result would be
> to return the same result as the first query).
>
> Removing the family filter while the qualifier is '10' yields expected
> results:
> {code:java}
> test.scan({ FILTER => "(
> SingleColumnValueFilter('a','10',=,'binary:',true,true) )"})
> ROW COLUMN+CELL
> 1column=a:1,
> timestamp=1520455887954, value=
> 1column=a:10,
> timestamp=1520455888024, value=
> 1column=b:2,
> timestamp=1520455888059, value=
> 1 row(s) in 0.0140 seconds
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20387) Fold flaky test finding into nightly job
[ https://issues.apache.org/jira/browse/HBASE-20387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434112#comment-16434112 ] Sean Busbey commented on HBASE-20387: - Current jobs for "find flaky tests": * master - https://builds.apache.org/view/H-L/view/HBase/job/HBase-Find-Flaky-Tests/ * branch-2.0 - https://builds.apache.org/view/H-L/view/HBase/job/HBase-Find-Flaky-Tests-branch2.0/ Note that we should keep the "run flaky tests" separate, since we probably want to keep running it more often. > Fold flaky test finding into nightly job > > > Key: HBASE-20387 > URL: https://issues.apache.org/jira/browse/HBASE-20387 > Project: HBase > Issue Type: Improvement > Components: test >Reporter: Sean Busbey >Priority: Critical > > We need a flaky list per-branch, since what does/does not work reliably on > master isn't really relevant to our older maintenance release lines. > We should just make the invocation a step in the current per-branch nightly > jobs, prior to when we need the list in the stages that run unit tests. We > can publish it in the nightly job as well so that precommit can still get it. > (and can fetch it per-branch if needed) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20381) precommit failing w/rat on shadedjars plugin
[ https://issues.apache.org/jira/browse/HBASE-20381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434049#comment-16434049 ] Sean Busbey commented on HBASE-20381: - build #12382 failed because it ran before HBASE-20068 landed. so I started another: https://builds.apache.org/job/PreCommit-HBASE-Build/12387/ and it passed everything. so this is a flaky issue. I'll update precommit to always look for rat.txt by default and we can address this again once it shows up. > precommit failing w/rat on shadedjars plugin > > > Key: HBASE-20381 > URL: https://issues.apache.org/jira/browse/HBASE-20381 > Project: HBase > Issue Type: Bug > Components: test >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Blocker > > see HBASE-20219 and related builds. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-20228) [Umbrella] Verify 1.2.7 shell works against 2.0.0 server
[ https://issues.apache.org/jira/browse/HBASE-20228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi resolved HBASE-20228. --- Resolution: Fixed All subtasks done. Resolving. > [Umbrella] Verify 1.2.7 shell works against 2.0.0 server > > > Key: HBASE-20228 > URL: https://issues.apache.org/jira/browse/HBASE-20228 > Project: HBase > Issue Type: Test > Components: shell >Affects Versions: 2.0.0-beta-2 >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Blocker > Fix For: 2.0.0 > > > Run 1.2.7 shell commands against 2.0.0 hbase and document which commands do > not work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19963) TestFSHDFSUtils assumes wrong default port for Hadoop 3.0.1+
[
https://issues.apache.org/jira/browse/HBASE-19963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang updated HBASE-19963:
Status: Patch Available (was: Open)
> TestFSHDFSUtils assumes wrong default port for Hadoop 3.0.1+
>
>
> Key: HBASE-19963
> URL: https://issues.apache.org/jira/browse/HBASE-19963
> Project: HBase
> Issue Type: Task
> Components: test
>Reporter: Mike Drob
>Assignee: Wei-Chiu Chuang
>Priority: Major
> Attachments: HBASE-19963.master.001.patch,
> HBASE-19963.master.002.patch
>
>
> We try to accommodate HDFS changing ports when testing if it is the same FS
> in our tests:
> https://github.com/apache/hbase/blob/master/hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestFSHDFSUtils.java#L156-L162
> {code}
> if (isHadoop3) {
> // Hadoop 3.0.0 alpha1+ change default nn port to 9820. See HDFS-9427
> testIsSameHdfs(9820);
> } else {
> // pre hadoop 3.0.0 defaults to port 8020
> testIsSameHdfs(8020);
> }
> {code}
> But in Hadoop 3.0.1, they decided to go back to the old port - see HDFS-12990.
> So our tests will fail against the snapshot and against future releases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20387) Fold flaky test finding into nightly job
[ https://issues.apache.org/jira/browse/HBASE-20387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-20387: Priority: Critical (was: Major) > Fold flaky test finding into nightly job > > > Key: HBASE-20387 > URL: https://issues.apache.org/jira/browse/HBASE-20387 > Project: HBase > Issue Type: Improvement > Components: test >Reporter: Sean Busbey >Priority: Critical > > We need a flaky list per-branch, since what does/does not work reliably on > master isn't really relevant to our older maintenance release lines. > We should just make the invocation a step in the current per-branch nightly > jobs, prior to when we need the list in the stages that run unit tests. We > can publish it in the nightly job as well so that precommit can still get it. > (and can fetch it per-branch if needed) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20385) Purge md5-making from our little make_rc.sh script
[ https://issues.apache.org/jira/browse/HBASE-20385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434119#comment-16434119 ] Josh Elser commented on HBASE-20385: +1 > Purge md5-making from our little make_rc.sh script > -- > > Key: HBASE-20385 > URL: https://issues.apache.org/jira/browse/HBASE-20385 > Project: HBase > Issue Type: Bug >Reporter: stack >Priority: Minor > Attachments: HBASE-20385.master.001.patch > > > Don't generate md5s anymore. New Apache release policy via Apache > Infrastructure asks that we not provide md5 as md5 is 'broken for many > purposes; we should movea awy from it.' Remove the md5' making from our > make-rc.sh script. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20389) Move website building flags into a profile
Sean Busbey created HBASE-20389:
---
Summary: Move website building flags into a profile
Key: HBASE-20389
URL: https://issues.apache.org/jira/browse/HBASE-20389
Project: HBase
Issue Type: Improvement
Components: build, website
Reporter: Sean Busbey
we have some "magic" in our website building right now. The script that's used
bout our automated website build + publish mechanism manually sets a bunch of
stuff on the maven command line.
It'd be better to reflect those settings in a maven profile, so that folks are
less likely to be surprised e.g. when trying to debug a failure in the {{site}}
goal happens.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20335) nightly jobs no longer contain machine information
[
https://issues.apache.org/jira/browse/HBASE-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434179#comment-16434179
]
Hudson commented on HBASE-20335:
Results for branch branch-2.0
[build #158 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> nightly jobs no longer contain machine information
> --
>
> Key: HBASE-20335
> URL: https://issues.apache.org/jira/browse/HBASE-20335
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-20335.0.patch
>
>
> something is up with nightly jobs. they no longer have the machine
> information from HBASE-19228.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20068) Hadoopcheck project health check uses default maven repo instead of yetus managed ones
[
https://issues.apache.org/jira/browse/HBASE-20068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434178#comment-16434178
]
Hudson commented on HBASE-20068:
Results for branch branch-2.0
[build #158 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Hadoopcheck project health check uses default maven repo instead of yetus
> managed ones
> --
>
> Key: HBASE-20068
> URL: https://issues.apache.org/jira/browse/HBASE-20068
> Project: HBase
> Issue Type: Bug
> Components: community, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20068.0.patch, HBASE-20068.1.patch
>
>
> Recently had a precommit run fail hadoop check for all 3 versions with
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:2.5.2:install (default-install)
> on project hbase-thrift: Failed to install metadata
> org.apache.hbase:hbase-thrift:3.0.0-SNAPSHOT/maven-metadata.xml: Could not
> parse metadata
> /home/jenkins/.m2/repository/org/apache/hbase/hbase-thrift/3.0.0-SNAPSHOT/maven-metadata-local.xml:
> in epilog non whitespace content is not allowed but got / (position: END_TAG
> seen ...\n/... @25:2) -> [Help 1]
> {code}
> Looks like maven repo corruption.
> Also the path {{/home/jenkins/.m2/repository}} means that those invocations
> are using the jenkins user repo, which isn't safe since there are multiple
> executors. either the plugin isn't using the yetus provided maven repo path
> or our yetus invocation isn't telling yetus to provide its own maven repo
> path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-15291) FileSystem not closed in secure bulkLoad
[
https://issues.apache.org/jira/browse/HBASE-15291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434181#comment-16434181
]
Hudson commented on HBASE-15291:
Results for branch branch-2.0
[build #158 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> FileSystem not closed in secure bulkLoad
>
>
> Key: HBASE-15291
> URL: https://issues.apache.org/jira/browse/HBASE-15291
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.2, 0.98.16.1
>Reporter: Yong Zhang
>Assignee: Ashish Singhi
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-15291-branch-1.2.patch,
> HBASE-15291-branch-1.patch, HBASE-15291-revert-master.patch,
> HBASE-15291.001.patch, HBASE-15291.002.patch, HBASE-15291.003.patch,
> HBASE-15291.004.patch, HBASE-15291.addendum, HBASE-15291.patch,
> HBASE-15291.v1.patch, HBASE-15291.v2.patch, HBASE-15291.v2.patch, patch
>
>
> FileSystem not closed in secure bulkLoad after bulkLoad finish, it will
> cause memory used more and more if too many bulkLoad .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20182) Can not locate region after split and merge
[
https://issues.apache.org/jira/browse/HBASE-20182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434180#comment-16434180
]
Hudson commented on HBASE-20182:
Results for branch branch-2.0
[build #158 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/158//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Can not locate region after split and merge
> ---
>
> Key: HBASE-20182
> URL: https://issues.apache.org/jira/browse/HBASE-20182
> Project: HBase
> Issue Type: Bug
> Components: Region Assignment
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-20182-UT.patch, HBASE-20182-addendum.patch,
> HBASE-20182-v1.patch, HBASE-20182-v2.patch, HBASE-20182-v3.patch,
> HBASE-20182-v3.patch, HBASE-20182-v3.patch, HBASE-20182.patch
>
>
> When implementing serial replication feature in HBASE-20046, I found that
> when splitting a region, we will not remove the parent region, instead we
> will mark it offline.
> And when locating a region, we will only scan one row so if we locate to the
> offlined region then we are dead.
> This will not happen for splitting, since one of the new daughter regions
> have the same start row with the parent region, and the timestamp is greater
> so when doing reverse scan we will always hit the daughter first.
> But if we also consider merge then bad things happen. Consider we have two
> regions A and B, we split B to C and D, and then merge A and C to E, then
> ideally the regions should be E and D, but actually the regions in meta will
> be E, B and D, and they all have different start rows. If you use a row
> within the range of old region C, then we will always locate to B and throw
> exception.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-15291) FileSystem not closed in secure bulkLoad
[
https://issues.apache.org/jira/browse/HBASE-15291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434221#comment-16434221
]
Hudson commented on HBASE-15291:
Results for branch branch-2
[build #598 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/598/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/598//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/598//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/598//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> FileSystem not closed in secure bulkLoad
>
>
> Key: HBASE-15291
> URL: https://issues.apache.org/jira/browse/HBASE-15291
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.0.2, 0.98.16.1
>Reporter: Yong Zhang
>Assignee: Ashish Singhi
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-15291-branch-1.2.patch,
> HBASE-15291-branch-1.patch, HBASE-15291-revert-master.patch,
> HBASE-15291.001.patch, HBASE-15291.002.patch, HBASE-15291.003.patch,
> HBASE-15291.004.patch, HBASE-15291.addendum, HBASE-15291.patch,
> HBASE-15291.v1.patch, HBASE-15291.v2.patch, HBASE-15291.v2.patch, patch
>
>
> FileSystem not closed in secure bulkLoad after bulkLoad finish, it will
> cause memory used more and more if too many bulkLoad .
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20182) Can not locate region after split and merge
[
https://issues.apache.org/jira/browse/HBASE-20182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434222#comment-16434222
]
Hudson commented on HBASE-20182:
Results for branch branch-2
[build #598 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/598/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/598//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/598//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/598//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Can not locate region after split and merge
> ---
>
> Key: HBASE-20182
> URL: https://issues.apache.org/jira/browse/HBASE-20182
> Project: HBase
> Issue Type: Bug
> Components: Region Assignment
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-20182-UT.patch, HBASE-20182-addendum.patch,
> HBASE-20182-v1.patch, HBASE-20182-v2.patch, HBASE-20182-v3.patch,
> HBASE-20182-v3.patch, HBASE-20182-v3.patch, HBASE-20182.patch
>
>
> When implementing serial replication feature in HBASE-20046, I found that
> when splitting a region, we will not remove the parent region, instead we
> will mark it offline.
> And when locating a region, we will only scan one row so if we locate to the
> offlined region then we are dead.
> This will not happen for splitting, since one of the new daughter regions
> have the same start row with the parent region, and the timestamp is greater
> so when doing reverse scan we will always hit the daughter first.
> But if we also consider merge then bad things happen. Consider we have two
> regions A and B, we split B to C and D, and then merge A and C to E, then
> ideally the regions should be E and D, but actually the regions in meta will
> be E, B and D, and they all have different start rows. If you use a row
> within the range of old region C, then we will always locate to B and throw
> exception.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20253) Error message is missing for restore_snapshot
[
https://issues.apache.org/jira/browse/HBASE-20253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434034#comment-16434034
]
Sean Busbey commented on HBASE-20253:
-
I agree that those all look like issues that just got marginally worse with the
patch. I'd prefer to disable the check since we're likely to keep ignoring it
anyways, but I don't feel strongly on that.
+1
> Error message is missing for restore_snapshot
> -
>
> Key: HBASE-20253
> URL: https://issues.apache.org/jira/browse/HBASE-20253
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Minor
> Attachments: HBASE-20253.master.001.patch,
> HBASE-20253.master.002.patch, HBASE-20253.master.003.patch,
> HBASE-20253.master.004.patch
>
>
> When the table is not disabled and restore_snapshot executed the error
> message is useless, only displays the table name.
> hbase(main):007:0> restore_snapshot 'tsnap'
> ERROR: t
> Restore a specified snapshot.
> The restore will replace the content of the original table,
> bringing back the content to the snapshot state.
> The table must be disabled.
> Examples:
> hbase> restore_snapshot 'snapshotName'
> Following command will restore all acl from snapshot table into the table.
> hbase> restore_snapshot 'snapshotName', \{RESTORE_ACL=>true}
> Took 0.1044 seconds
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HBASE-20381) precommit failing w/rat on shadedjars plugin
[ https://issues.apache.org/jira/browse/HBASE-20381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey resolved HBASE-20381. - Resolution: Cannot Reproduce Assignee: (was: Sean Busbey) okay I updated the default parameter for the precommit job. closing this out for now. > precommit failing w/rat on shadedjars plugin > > > Key: HBASE-20381 > URL: https://issues.apache.org/jira/browse/HBASE-20381 > Project: HBase > Issue Type: Bug > Components: test >Reporter: Sean Busbey >Priority: Blocker > > see HBASE-20219 and related builds. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19963) TestFSHDFSUtils assumes wrong default port for Hadoop 3.0.1+
[
https://issues.apache.org/jira/browse/HBASE-19963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434090#comment-16434090
]
Wei-Chiu Chuang commented on HBASE-19963:
-
Got it. I didn't pay much attention to Hadoop client side jars before... :)
Posted a patch to detect Hadoop version. The versions starting with 3.0.0
(3.0.0-alpha1, 3.0.0-alpha2, 3.0.0-alpha4, 3.0.0-beta1 and 3.0.0) were
affected, whereas pre-3.0.0 and 3.0.1 and above use the old ports.
Didn't change hadoop-three.version since 3.0.2 is still being baked.
> TestFSHDFSUtils assumes wrong default port for Hadoop 3.0.1+
>
>
> Key: HBASE-19963
> URL: https://issues.apache.org/jira/browse/HBASE-19963
> Project: HBase
> Issue Type: Task
> Components: test
>Reporter: Mike Drob
>Assignee: Wei-Chiu Chuang
>Priority: Major
> Attachments: HBASE-19963.master.001.patch,
> HBASE-19963.master.002.patch
>
>
> We try to accommodate HDFS changing ports when testing if it is the same FS
> in our tests:
> https://github.com/apache/hbase/blob/master/hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestFSHDFSUtils.java#L156-L162
> {code}
> if (isHadoop3) {
> // Hadoop 3.0.0 alpha1+ change default nn port to 9820. See HDFS-9427
> testIsSameHdfs(9820);
> } else {
> // pre hadoop 3.0.0 defaults to port 8020
> testIsSameHdfs(8020);
> }
> {code}
> But in Hadoop 3.0.1, they decided to go back to the old port - see HDFS-12990.
> So our tests will fail against the snapshot and against future releases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20388) nightly tests running on a feature branch should only comment on that feature branch's jira
Sean Busbey created HBASE-20388: --- Summary: nightly tests running on a feature branch should only comment on that feature branch's jira Key: HBASE-20388 URL: https://issues.apache.org/jira/browse/HBASE-20388 Project: HBase Issue Type: Improvement Components: community, test Reporter: Sean Busbey It would help improve our signal-to-noise ratio from nightly tests if feature branch runs stopped commenting on all the jiras that got covered by a rebase / merge. should be straight forward to have the commenting bit check the current branch against our feature branch naming convention. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20294) Also cleanup last pushed sequence id in ReplicationBarrierCleaner
[
https://issues.apache.org/jira/browse/HBASE-20294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434216#comment-16434216
]
Hadoop QA commented on HBASE-20294:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
21s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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
1s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
17s{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
44s{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:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
31s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
0s{color} | {color:red} hbase-server: The patch generated 1 new + 0 unchanged -
0 fixed = 1 total (was 0) {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
13s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
13m 11s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}153m
43s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}194m 51s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20294 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12918559/HBASE-20294.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 226d57dbb27e 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11
12:16:42 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 37e5b0b1b7 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/12394/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12394/testReport/ |
| Max. process+thread count | 4541 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
[jira] [Commented] (HBASE-20219) An error occurs when scanning with reversed=true and loadColumnFamiliesOnDemand=true
[
https://issues.apache.org/jira/browse/HBASE-20219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434060#comment-16434060
]
Sean Busbey commented on HBASE-20219:
-
Run looks good. Unfortunately that's without me actually changing anything. So
I've closed out HBASE-20381 as cannot reproduce. Details on that issue about
measures in place to make sure we can root cause when the issue shows up again.
reviewers should feel free to continue with the patch as they see fit; I no
longer have an objection based on the shadedjars test.
> An error occurs when scanning with reversed=true and
> loadColumnFamiliesOnDemand=true
>
>
> Key: HBASE-20219
> URL: https://issues.apache.org/jira/browse/HBASE-20219
> Project: HBase
> Issue Type: Bug
> Components: phoenix
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20219-UT.patch, HBASE-20219.master.001.patch,
> HBASE-20219.master.002.patch, HBASE-20219.master.003.patch,
> HBASE-20219.master.004.patch
>
>
> I'm facing the following error when scanning with reversed=true and
> loadColumnFamiliesOnDemand=true:
> {code}
> java.lang.IllegalStateException: requestSeek cannot be called on
> ReversedKeyValueHeap
> at
> org.apache.hadoop.hbase.regionserver.ReversedKeyValueHeap.requestSeek(ReversedKeyValueHeap.java:66)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.joinedHeapMayHaveData(HRegion.java:6725)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextInternal(HRegion.java:6652)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:6364)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.scan(RSRpcServices.java:3108)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.scan(RSRpcServices.java:3345)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:41548)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:409)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
> {code}
> I will attach a UT patch to reproduce this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20335) nightly jobs no longer contain machine information
[ https://issues.apache.org/jira/browse/HBASE-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434108#comment-16434108 ] Sean Busbey commented on HBASE-20335: - branch builds while it lasts: https://builds.apache.org/job/HBase%20Nightly/job/HBASE-20355 > nightly jobs no longer contain machine information > -- > > Key: HBASE-20335 > URL: https://issues.apache.org/jira/browse/HBASE-20335 > Project: HBase > Issue Type: Bug > Components: test >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Attachments: HBASE-20335.0.patch > > > something is up with nightly jobs. they no longer have the machine > information from HBASE-19228. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
