[jira] [Updated] (HBASE-19622) Reimplement ReplicationPeers with the new replication storage interface
[ https://issues.apache.org/jira/browse/HBASE-19622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-19622: - Attachment: HBASE-19622.v8.HBASE-19397.patch > Reimplement ReplicationPeers with the new replication storage interface > --- > > Key: HBASE-19622 > URL: https://issues.apache.org/jira/browse/HBASE-19622 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Replication >Reporter: Guanghao Zhang >Assignee: Zheng Hu > Fix For: HBASE-19397 > > Attachments: HBASE-19622.v1.HBASE-19397.patch, > HBASE-19622.v2.HBASE-19397.patch, HBASE-19622.v3.HBASE-19397.patch, > HBASE-19622.v4.HBASE-19397.patch, HBASE-19622.v5.HBASE-19397.patch, > HBASE-19622.v5.HBASE-19397.patch, HBASE-19622.v6.HBASE-19397.patch, > HBASE-19622.v7.HBASE-19397.patch, HBASE-19622.v8.HBASE-19397.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19622) Reimplement ReplicationPeers with the new replication storage interface
[
https://issues.apache.org/jira/browse/HBASE-19622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306120#comment-16306120
]
Hadoop QA commented on HBASE-19622:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 8 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-19397 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
34s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
59s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
10s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
45s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
23s{color} | {color:green} HBASE-19397 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
36s{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} 0m
27s{color} | {color:green} The patch hbase-client passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s{color} | {color:green} The patch hbase-zookeeper passed checkstyle {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
11s{color} | {color:red} hbase-replication: The patch generated 1 new + 3
unchanged - 6 fixed = 4 total (was 9) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
2s{color} | {color:green} hbase-server: The patch generated 0 new + 41
unchanged - 3 fixed = 41 total (was 44) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
16s{color} | {color:green} The patch hbase-mapreduce 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
40s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
19m 21s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
23s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
33s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
34s{color} | {color:green} hbase-zookeeper in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
15s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}106m 27s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 9m
58s{color} | {color:green} hbase-mapreduce in t
[jira] [Commented] (HBASE-19633) Clean up the replication queues in the postPeerModification stage when removing a peer
[ https://issues.apache.org/jira/browse/HBASE-19633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306132#comment-16306132 ] Guanghao Zhang commented on HBASE-19633: bq. queueStorage.removeReplicatorIfQueueIsEmpty(replicator); This should move to the outer loop? > Clean up the replication queues in the postPeerModification stage when > removing a peer > -- > > Key: HBASE-19633 > URL: https://issues.apache.org/jira/browse/HBASE-19633 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Replication >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-19633-HBASE-19397-v1.patch, > HBASE-19633-HBASE-19397.patch > > > In the previous implementation, we can not always cleanly remove all the > replication queues when removing a peer since the removing work is done by RS > and if an RS is crashed then some queues may left there forever. That's why > we need to check if there are already some queues for a newly created peer > since we may reuse the peer id and causes problem. > With the new procedure based replication peer modification, I think we can do > it cleanly. After the RefreshPeerProcedures are done on all RSes, we can make > sure that no RS will create queue for this peer again, then we can iterate > over all the queues for all Rses and do another round of clean up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19622) Reimplement ReplicationPeers with the new replication storage interface
[ https://issues.apache.org/jira/browse/HBASE-19622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-19622: - Attachment: HBASE-19622.v8.HBASE-19397.patch > Reimplement ReplicationPeers with the new replication storage interface > --- > > Key: HBASE-19622 > URL: https://issues.apache.org/jira/browse/HBASE-19622 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Replication >Reporter: Guanghao Zhang >Assignee: Zheng Hu > Fix For: HBASE-19397 > > Attachments: HBASE-19622.v1.HBASE-19397.patch, > HBASE-19622.v2.HBASE-19397.patch, HBASE-19622.v3.HBASE-19397.patch, > HBASE-19622.v4.HBASE-19397.patch, HBASE-19622.v5.HBASE-19397.patch, > HBASE-19622.v5.HBASE-19397.patch, HBASE-19622.v6.HBASE-19397.patch, > HBASE-19622.v7.HBASE-19397.patch, HBASE-19622.v8.HBASE-19397.patch, > HBASE-19622.v8.HBASE-19397.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19483) Add proper privilege check for rsgroup commands
[ https://issues.apache.org/jira/browse/HBASE-19483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-19483: --- Attachment: 19483.v11.patch Patch v11 was regenerated from Guangxu's patch. > Add proper privilege check for rsgroup commands > --- > > Key: HBASE-19483 > URL: https://issues.apache.org/jira/browse/HBASE-19483 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Guangxu Cheng > Fix For: 1.4.1, 1.5.0, 2.0.0-beta-2 > > Attachments: 19483.master.011.patch, 19483.v11.patch, > 19483.v11.patch, HBASE-19483.master.001.patch, HBASE-19483.master.002.patch, > HBASE-19483.master.003.patch, HBASE-19483.master.004.patch, > HBASE-19483.master.005.patch, HBASE-19483.master.006.patch, > HBASE-19483.master.007.patch, HBASE-19483.master.008.patch, > HBASE-19483.master.009.patch, HBASE-19483.master.010.patch, > HBASE-19483.master.011.patch, HBASE-19483.master.011.patch > > > Currently list_rsgroups command can be executed by any user. > This is inconsistent with other list commands such as list_peers and > list_peer_configs. > We should add proper privilege check for list_rsgroups command. > privilege check should be added for get_table_rsgroup / get_server_rsgroup / > get_rsgroup commands. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19358) Improve the stability of splitting log when do fail over
[ https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-19358: - Attachment: HBASE-19358-branch-1.patch > Improve the stability of splitting log when do fail over > > > Key: HBASE-19358 > URL: https://issues.apache.org/jira/browse/HBASE-19358 > Project: HBase > Issue Type: Improvement > Components: MTTR >Affects Versions: 0.98.24 >Reporter: Jingyun Tian >Assignee: Jingyun Tian > Attachments: HBASE-18619-branch-2.patch, HBASE-19358-branch-1.patch, > HBASE-19358-v1.patch, HBASE-19358-v4.patch, HBASE-19358-v5.patch, > HBASE-19358-v6.patch, HBASE-19358-v7.patch, HBASE-19358-v8.patch, > HBASE-19358.patch > > > The way we splitting log now is like the following figure: > !https://issues.apache.org/jira/secure/attachment/12902997/split-logic-old.jpg! > The problem is the OutputSink will write the recovered edits during splitting > log, which means it will create one WriterAndPath for each region and retain > it until the end. If the cluster is small and the number of regions per rs is > large, it will create too many HDFS streams at the same time. Then it is > prone to failure since each datanode need to handle too many streams. > Thus I come up with a new way to split log. > !https://issues.apache.org/jira/secure/attachment/12902998/split-logic-new.jpg! > We try to cache all the recovered edits, but if it exceeds the MaxHeapUsage, > we will pick the largest EntryBuffer and write it to a file (close the writer > after finish). Then after we read all entries into memory, we will start a > writeAndCloseThreadPool, it starts a certain number of threads to write all > buffers to files. Thus it will not create HDFS streams more than > *_hbase.regionserver.hlog.splitlog.writer.threads_* we set. > The biggest benefit is we can control the number of streams we create during > splitting log, > it will not exceeds *_hbase.regionserver.wal.max.splitters * > hbase.regionserver.hlog.splitlog.writer.threads_*, but before it is > *_hbase.regionserver.wal.max.splitters * the number of region the hlog > contains_*. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19358) Improve the stability of splitting log when do fail over
[ https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-19358: - Attachment: (was: HBASE-19358-branch-1.patch) > Improve the stability of splitting log when do fail over > > > Key: HBASE-19358 > URL: https://issues.apache.org/jira/browse/HBASE-19358 > Project: HBase > Issue Type: Improvement > Components: MTTR >Affects Versions: 0.98.24 >Reporter: Jingyun Tian >Assignee: Jingyun Tian > Attachments: HBASE-18619-branch-2.patch, HBASE-19358-branch-1.patch, > HBASE-19358-v1.patch, HBASE-19358-v4.patch, HBASE-19358-v5.patch, > HBASE-19358-v6.patch, HBASE-19358-v7.patch, HBASE-19358-v8.patch, > HBASE-19358.patch > > > The way we splitting log now is like the following figure: > !https://issues.apache.org/jira/secure/attachment/12902997/split-logic-old.jpg! > The problem is the OutputSink will write the recovered edits during splitting > log, which means it will create one WriterAndPath for each region and retain > it until the end. If the cluster is small and the number of regions per rs is > large, it will create too many HDFS streams at the same time. Then it is > prone to failure since each datanode need to handle too many streams. > Thus I come up with a new way to split log. > !https://issues.apache.org/jira/secure/attachment/12902998/split-logic-new.jpg! > We try to cache all the recovered edits, but if it exceeds the MaxHeapUsage, > we will pick the largest EntryBuffer and write it to a file (close the writer > after finish). Then after we read all entries into memory, we will start a > writeAndCloseThreadPool, it starts a certain number of threads to write all > buffers to files. Thus it will not create HDFS streams more than > *_hbase.regionserver.hlog.splitlog.writer.threads_* we set. > The biggest benefit is we can control the number of streams we create during > splitting log, > it will not exceeds *_hbase.regionserver.wal.max.splitters * > hbase.regionserver.hlog.splitlog.writer.threads_*, but before it is > *_hbase.regionserver.wal.max.splitters * the number of region the hlog > contains_*. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19663) site build fails complaining "javadoc: error - class file for javax.annotation.meta.TypeQualifierNickname not found"
stack created HBASE-19663:
-
Summary: site build fails complaining "javadoc: error - class file
for javax.annotation.meta.TypeQualifierNickname not found"
Key: HBASE-19663
URL: https://issues.apache.org/jira/browse/HBASE-19663
Project: HBase
Issue Type: Bug
Components: site
Reporter: stack
Assignee: stack
Priority: Blocker
Cryptic failure trying to build beta-1 RC. Fails like this:
{code}
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 03:54 min
[INFO] Finished at: 2017-12-29T01:13:15-08:00
[INFO] Final Memory: 381M/9165M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
hbase: Error generating maven-javadoc-plugin:2.10.3:aggregate:
[ERROR] Exit code: 1 - warning: unknown enum constant When.ALWAYS
[ERROR] reason: class file for javax.annotation.meta.When not found
[ERROR] warning: unknown enum constant When.UNKNOWN
[ERROR] warning: unknown enum constant When.MAYBE
[ERROR]
/home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
warning - Tag @link: malformed: "#matchingRows(Cell, byte[]))"
[ERROR]
/home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
[ERROR]
/home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
[ERROR] javadoc: warning - Class javax.annotation.Nonnull not found.
[ERROR] javadoc: error - class file for
javax.annotation.meta.TypeQualifierNickname not found
[ERROR]
[ERROR] Command line was: /home/stack/bin/jdk1.8.0_151/jre/../bin/javadoc
-J-Xmx2G @options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'/home/stack/hbase.git/target/site/apidocs' dir.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
{code}
javax.annotation.meta.TypeQualifierNickname is out of jsr305 but we don't
include this anywhere according to mvn dependency.
Happens building the User API both test and main.
Excluding these lines gets us passing again:
{code}
3511
3512
org.apache.yetus.audience.tools.IncludePublicAnnotationsStandardDoclet
3513
3514
3515 org.apache.yetus
3516 audience-annotations
3517 ${audience-annotations.version}
3518
+ 3519 true
{code}
Tried upgrading to newer mvn site (ours is three years old) but that a
different set of problems.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19663) site build fails complaining "javadoc: error - class file for javax.annotation.meta.TypeQualifierNickname not found"
[
https://issues.apache.org/jira/browse/HBASE-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-19663:
--
Fix Version/s: 2.0.0-beta-1
> site build fails complaining "javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found"
>
>
> Key: HBASE-19663
> URL: https://issues.apache.org/jira/browse/HBASE-19663
> Project: HBase
> Issue Type: Bug
> Components: site
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0-beta-1
>
>
> Cryptic failure trying to build beta-1 RC. Fails like this:
> {code}
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 03:54 min
> [INFO] Finished at: 2017-12-29T01:13:15-08:00
> [INFO] Final Memory: 381M/9165M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
> hbase: Error generating maven-javadoc-plugin:2.10.3:aggregate:
> [ERROR] Exit code: 1 - warning: unknown enum constant When.ALWAYS
> [ERROR] reason: class file for javax.annotation.meta.When not found
> [ERROR] warning: unknown enum constant When.UNKNOWN
> [ERROR] warning: unknown enum constant When.MAYBE
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: malformed: "#matchingRows(Cell, byte[]))"
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR] javadoc: warning - Class javax.annotation.Nonnull not found.
> [ERROR] javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found
> [ERROR]
> [ERROR] Command line was: /home/stack/bin/jdk1.8.0_151/jre/../bin/javadoc
> -J-Xmx2G @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/stack/hbase.git/target/site/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}
> javax.annotation.meta.TypeQualifierNickname is out of jsr305 but we don't
> include this anywhere according to mvn dependency.
> Happens building the User API both test and main.
> Excluding these lines gets us passing again:
> {code}
> 3511
> 3512
> org.apache.yetus.audience.tools.IncludePublicAnnotationsStandardDoclet
> 3513
> 3514
> 3515 org.apache.yetus
> 3516 audience-annotations
> 3517 ${audience-annotations.version}
> 3518
> + 3519 true
> {code}
> Tried upgrading to newer mvn site (ours is three years old) but that a
> different set of problems.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19664) MOB should compatible with other types of Compactor in addition to DefaultCompactor
chenxu created HBASE-19664: -- Summary: MOB should compatible with other types of Compactor in addition to DefaultCompactor Key: HBASE-19664 URL: https://issues.apache.org/jira/browse/HBASE-19664 Project: HBase Issue Type: Improvement Components: mob Reporter: chenxu Currently when MOB feature enabled, we will use MobStoreEngine to deal with flush and compaction, but it extends DefaultStoreEngine, so the stripe compaction feature can not be used. In some scenes, Stripe Compaction are very useful, it can reduce the number of regions and prevent a single storefile grow too large，If it can compatible with MOB feature, that’s perfect. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19664) MOB should compatible with other types of Compactor in addition to DefaultCompactor
[ https://issues.apache.org/jira/browse/HBASE-19664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenxu updated HBASE-19664: --- Description: Currently when MOB feature enabled, we will use MobStoreEngine to deal with flush and compaction, but it extends DefaultStoreEngine, so the stripe compaction feature can not be used. In some scenes, Stripe Compaction are very useful, it can reduce the number of regions and prevent a single storefile grow too large，If it compatible with MOB feature, that’s perfect. was: Currently when MOB feature enabled, we will use MobStoreEngine to deal with flush and compaction, but it extends DefaultStoreEngine, so the stripe compaction feature can not be used. In some scenes, Stripe Compaction are very useful, it can reduce the number of regions and prevent a single storefile grow too large，If it can compatible with MOB feature, that’s perfect. > MOB should compatible with other types of Compactor in addition to > DefaultCompactor > --- > > Key: HBASE-19664 > URL: https://issues.apache.org/jira/browse/HBASE-19664 > Project: HBase > Issue Type: Improvement > Components: mob >Reporter: chenxu > > Currently when MOB feature enabled, we will use MobStoreEngine to deal with > flush and compaction, but it extends DefaultStoreEngine, so the stripe > compaction feature can not be used. > In some scenes, Stripe Compaction are very useful, it can reduce the number > of regions and prevent a single storefile grow too large，If it > compatible with MOB feature, that’s perfect. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19665) Add table based replication queues storage back
Guanghao Zhang created HBASE-19665: -- Summary: Add table based replication queues storage back Key: HBASE-19665 URL: https://issues.apache.org/jira/browse/HBASE-19665 Project: HBase Issue Type: Sub-task Reporter: Guanghao Zhang I removed them in HBASE-19618. So open a issue to track this thing. We should add the table based replication queues storage back after we merged HBASE-19397 to master/branch-2. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19358) Improve the stability of splitting log when do fail over
[ https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306160#comment-16306160 ] Jingyun Tian commented on HBASE-19358: -- hadoop.hbase.regionserver.TestDefaultCompactSelection failed is not related to my patch. Reported and try to fix.. > Improve the stability of splitting log when do fail over > > > Key: HBASE-19358 > URL: https://issues.apache.org/jira/browse/HBASE-19358 > Project: HBase > Issue Type: Improvement > Components: MTTR >Affects Versions: 0.98.24 >Reporter: Jingyun Tian >Assignee: Jingyun Tian > Attachments: HBASE-18619-branch-2.patch, HBASE-19358-branch-1.patch, > HBASE-19358-v1.patch, HBASE-19358-v4.patch, HBASE-19358-v5.patch, > HBASE-19358-v6.patch, HBASE-19358-v7.patch, HBASE-19358-v8.patch, > HBASE-19358.patch > > > The way we splitting log now is like the following figure: > !https://issues.apache.org/jira/secure/attachment/12902997/split-logic-old.jpg! > The problem is the OutputSink will write the recovered edits during splitting > log, which means it will create one WriterAndPath for each region and retain > it until the end. If the cluster is small and the number of regions per rs is > large, it will create too many HDFS streams at the same time. Then it is > prone to failure since each datanode need to handle too many streams. > Thus I come up with a new way to split log. > !https://issues.apache.org/jira/secure/attachment/12902998/split-logic-new.jpg! > We try to cache all the recovered edits, but if it exceeds the MaxHeapUsage, > we will pick the largest EntryBuffer and write it to a file (close the writer > after finish). Then after we read all entries into memory, we will start a > writeAndCloseThreadPool, it starts a certain number of threads to write all > buffers to files. Thus it will not create HDFS streams more than > *_hbase.regionserver.hlog.splitlog.writer.threads_* we set. > The biggest benefit is we can control the number of streams we create during > splitting log, > it will not exceeds *_hbase.regionserver.wal.max.splitters * > hbase.regionserver.hlog.splitlog.writer.threads_*, but before it is > *_hbase.regionserver.wal.max.splitters * the number of region the hlog > contains_*. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19666) hadoop.hbase.regionserver.TestDefaultCompactSelection test failed
Jingyun Tian created HBASE-19666: Summary: hadoop.hbase.regionserver.TestDefaultCompactSelection test failed Key: HBASE-19666 URL: https://issues.apache.org/jira/browse/HBASE-19666 Project: HBase Issue Type: Bug Affects Versions: 2.0 Reporter: Jingyun Tian Priority: Critical hadoop.hbase.regionserver.TestDefaultCompactSelection [ERROR] Failures: [ERROR] TestDefaultCompactSelection.testCompactionRatio:74->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 expected:<[[4, 2, 1]]> but was:<[[]]> [ERROR] TestDefaultCompactSelection.testStuckStoreCompaction:145->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 expected:<[[]30, 30, 30]> but was:<[[99, 30, ]30, 30, 30]> -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-17303) Let master to check and transfer the dead rs's replication queues
[
https://issues.apache.org/jira/browse/HBASE-17303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang resolved HBASE-17303.
Resolution: Duplicate
Duplicate with HBASE-19633. And this problem will not exist after HBASE-19397.
> Let master to check and transfer the dead rs's replication queues
> -
>
> Key: HBASE-17303
> URL: https://issues.apache.org/jira/browse/HBASE-17303
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>
> Dump replication queues result from our cluster.
> {code}
> Found 8 deleted queues, run hbck -fixReplication in order to remove the
> deleted replication queues
> hostname,24610,1481528189915/80-hostname,24620,1476784763605
>
> hostname,24620,1476784763605/70-hostname,24630,1470418208092-hostname,24600,1476773709589
>
> hostname,24630,1481528526258/17000-hostname,24620,1470044455538-hostname,24630,1470037674231-hostname,24600,1476773708489-hostname,24620,1476784763605
>
> hostname,24620,1481528358531/70-hostname,24600,1476773709589-hostname,24620,1476784763605
>
> hostname,24600,1481528021595/70-hostname,24630,1470421093464-hostname,24630,1476773708939-hostname,24610,1476779010928-hostname,24620,1476784747260
> hostname,24600,1481528021595/17000-hostname,24620,1476784763605
>
> hostname,24600,1481528021595/17000-hostname,24630,1475381530644-hostname,24600,1476773709589-hostname,24620,1476784763605
>
> hostname,24600,1481528021595/17000-hostname,24600,1476773709589-hostname,24620,1476784763605
> Found 2 dead regionservers, restart one regionserver to transfer the queues
> of dead regionservers
> hostname,24600,1481547616148
> hostname,24620,1476784763605
> {code}
> Now for dead rs's replication znode, you need restart one regionserver to
> transfer the replication queues of dead regionservers. Same idea with
> HBASE-16336, we can let master to periodically check the dead rs znode, too.
> And send the transfer replication queues request to any regionserver. Then
> the dead rs's replication queues can be transfer automatically and don't need
> to wait a regionserver restart. Any suggestions are welcomed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19622) Reimplement ReplicationPeers with the new replication storage interface
[ https://issues.apache.org/jira/browse/HBASE-19622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306176#comment-16306176 ] Guanghao Zhang commented on HBASE-19622: +1. You can commit it after get a green Hadoop QA result. > Reimplement ReplicationPeers with the new replication storage interface > --- > > Key: HBASE-19622 > URL: https://issues.apache.org/jira/browse/HBASE-19622 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Replication >Reporter: Guanghao Zhang >Assignee: Zheng Hu > Fix For: HBASE-19397 > > Attachments: HBASE-19622.v1.HBASE-19397.patch, > HBASE-19622.v2.HBASE-19397.patch, HBASE-19622.v3.HBASE-19397.patch, > HBASE-19622.v4.HBASE-19397.patch, HBASE-19622.v5.HBASE-19397.patch, > HBASE-19622.v5.HBASE-19397.patch, HBASE-19622.v6.HBASE-19397.patch, > HBASE-19622.v7.HBASE-19397.patch, HBASE-19622.v8.HBASE-19397.patch, > HBASE-19622.v8.HBASE-19397.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19133) Transfer big cells or upserted/appended cells into MSLAB upon flattening to CellChunkMap
[ https://issues.apache.org/jira/browse/HBASE-19133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306177#comment-16306177 ] ramkrishna.s.vasudevan commented on HBASE-19133: Belated +1. > Transfer big cells or upserted/appended cells into MSLAB upon flattening to > CellChunkMap > > > Key: HBASE-19133 > URL: https://issues.apache.org/jira/browse/HBASE-19133 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Gali Sheffi > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19133-V01.patch, HBASE-19133-V02.patch, > HBASE-19133-V03.patch, HBASE-19133.01.patch, HBASE-19133.02.patch, > HBASE-19133.03.patch, HBASE-19133.04.patch, HBASE-19133.05.patch, > HBASE-19133.06.patch, HBASE-19133.07.patch, HBASE-19133.08.patch, > HBASE-19133.09.patch, HBASE-19133.10.patch, HBASE-19133.11.patch > > > CellChunkMap Segment index requires all cell data to be written in the MSLAB > Chunks. Eventhough MSLAB is enabled, cells bigger than chunk size or > upserted/incremented/appended cells are still allocated on the JVM stack. If > such cells are found in the process of flattening into CellChunkMap > (in-memory-flush) they need to be copied into MSLAB. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19196) Release hbase-2.0.0-beta-1; the "Finish-line" release
[ https://issues.apache.org/jira/browse/HBASE-19196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306178#comment-16306178 ] stack commented on HBASE-19196: --- Tagged branch-2 with 2.0.0-beta-1-RC0. Trying to figure the cryptic failure over in HBASE-19663. > Release hbase-2.0.0-beta-1; the "Finish-line" release > - > > Key: HBASE-19196 > URL: https://issues.apache.org/jira/browse/HBASE-19196 > Project: HBase > Issue Type: Bug >Reporter: stack >Priority: Blocker > Fix For: 2.0.0-beta-1 > > > APIs done, but external facing and Coprocessors. Done w/ features. Bug fixes > only from here on out. There'll be a beta-2 but that is about rolling upgrade > and bug fixes only. Then our first 2.0.0 Release Candidate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19486) Periodically ensure records are not buffered too long by BufferedMutator
[
https://issues.apache.org/jira/browse/HBASE-19486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306179#comment-16306179
]
Niels Basjes commented on HBASE-19486:
--
[~chia7712]
The BFImpl#close does a call to {{disableWriteBufferPeriodicFlush();}} which
cancels the running timer if present.
So to me this seem "not a problem" as far as I can see.
I'm preparing the branch-1 patch now.
> Periodically ensure records are not buffered too long by BufferedMutator
> -
>
> Key: HBASE-19486
> URL: https://issues.apache.org/jira/browse/HBASE-19486
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Reporter: Niels Basjes
>Assignee: Niels Basjes
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19486-20171212-2117.patch,
> HBASE-19486-20171218-1229.patch, HBASE-19486-20171218-1300.patch,
> HBASE-19486-20171219-0933.patch, HBASE-19486-20171219-1026.patch,
> HBASE-19486-20171219-1122-trigger-qa-run.patch,
> HBASE-19486-20171220-1612-trigger-qa-run.patch,
> HBASE-19486-20171220-2228-trigger-qa-run.patch,
> HBASE-19486-20171223-1438-trigger-qa-run.patch,
> HBASE-19486-20171223-1728-trigger-qa-run.patch,
> HBASE-19486-20171223--trigger-qa-run.patch,
> HBASE-19486-20171224-1101-trigger-qa-run.patch,
> HBASE-19486-20171224-1602.patch, HBASE-19486.v0.patch
>
>
> I'm working on several projects where we are doing stream / event type
> processing instead of batch type processing. We mostly use Apache Flink and
> Apache Beam for these projects.
> When we ingest a continuous stream of events and feed that into HBase via a
> BufferedMutator this all works fine. The buffer fills up at a predictable
> rate and we can make sure it flushes several times per second into HBase by
> tuning the buffer size.
> We also have situations where the event rate is unpredictable. Some times
> because the source is in reality a batch job that puts records into Kafka,
> sometimes because it is the "predictable in production" application in our
> testing environment (where only the dev triggers a handful of events).
> For these kinds of use cases we need a way to 'force' the BufferedMutator to
> automatically flush any records in the buffer even if the buffer is not full.
> I'll put up a pull request with a proposed implementation for review against
> the master (i.e. 3.0.0).
> When approved I would like to backport this to the 1.x and 2.x versions of
> the client in the same (as close as possible) way.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19483) Add proper privilege check for rsgroup commands
[
https://issues.apache.org/jira/browse/HBASE-19483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306200#comment-16306200
]
Hadoop QA commented on HBASE-19483:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 9 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
56s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
11s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 9m
59s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 5m
9s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
11s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
5s{color} | {color:green} hbase-server: The patch generated 0 new + 82
unchanged - 11 fixed = 82 total (was 93) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
19s{color} | {color:green} The patch hbase-mapreduce passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
29s{color} | {color:green} hbase-thrift: The patch generated 0 new + 0
unchanged - 283 fixed = 0 total (was 283) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
11s{color} | {color:green} The patch hbase-rsgroup passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s{color} | {color:green} The patch hbase-it passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
14s{color} | {color:green} The patch hbase-rest passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
22s{color} | {color:green} root: The patch generated 0 new + 138 unchanged -
294 fixed = 138 total (was 432) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
48s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 2s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m
44s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 36m 45s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
26s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}103m 43s{c
[jira] [Commented] (HBASE-19483) Add proper privilege check for rsgroup commands
[ https://issues.apache.org/jira/browse/HBASE-19483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306204#comment-16306204 ] Guangxu Cheng commented on HBASE-19483: --- Checked the test report, TestThriftServerCmdLine failure was not related. > Add proper privilege check for rsgroup commands > --- > > Key: HBASE-19483 > URL: https://issues.apache.org/jira/browse/HBASE-19483 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Guangxu Cheng > Fix For: 1.4.1, 1.5.0, 2.0.0-beta-2 > > Attachments: 19483.master.011.patch, 19483.v11.patch, > 19483.v11.patch, HBASE-19483.master.001.patch, HBASE-19483.master.002.patch, > HBASE-19483.master.003.patch, HBASE-19483.master.004.patch, > HBASE-19483.master.005.patch, HBASE-19483.master.006.patch, > HBASE-19483.master.007.patch, HBASE-19483.master.008.patch, > HBASE-19483.master.009.patch, HBASE-19483.master.010.patch, > HBASE-19483.master.011.patch, HBASE-19483.master.011.patch > > > Currently list_rsgroups command can be executed by any user. > This is inconsistent with other list commands such as list_peers and > list_peer_configs. > We should add proper privilege check for list_rsgroups command. > privilege check should be added for get_table_rsgroup / get_server_rsgroup / > get_rsgroup commands. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19486) Periodically ensure records are not buffered too long by BufferedMutator
[
https://issues.apache.org/jira/browse/HBASE-19486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306208#comment-16306208
]
Chia-Ping Tsai commented on HBASE-19486:
{quote}
The BFImpl#close does a call to disableWriteBufferPeriodicFlush(); which
cancels the running timer if present.
So to me this seem "not a problem" as far as I can see.
{quote}
Thanks! I missed that.
> Periodically ensure records are not buffered too long by BufferedMutator
> -
>
> Key: HBASE-19486
> URL: https://issues.apache.org/jira/browse/HBASE-19486
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Reporter: Niels Basjes
>Assignee: Niels Basjes
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19486-20171212-2117.patch,
> HBASE-19486-20171218-1229.patch, HBASE-19486-20171218-1300.patch,
> HBASE-19486-20171219-0933.patch, HBASE-19486-20171219-1026.patch,
> HBASE-19486-20171219-1122-trigger-qa-run.patch,
> HBASE-19486-20171220-1612-trigger-qa-run.patch,
> HBASE-19486-20171220-2228-trigger-qa-run.patch,
> HBASE-19486-20171223-1438-trigger-qa-run.patch,
> HBASE-19486-20171223-1728-trigger-qa-run.patch,
> HBASE-19486-20171223--trigger-qa-run.patch,
> HBASE-19486-20171224-1101-trigger-qa-run.patch,
> HBASE-19486-20171224-1602.patch, HBASE-19486.v0.patch
>
>
> I'm working on several projects where we are doing stream / event type
> processing instead of batch type processing. We mostly use Apache Flink and
> Apache Beam for these projects.
> When we ingest a continuous stream of events and feed that into HBase via a
> BufferedMutator this all works fine. The buffer fills up at a predictable
> rate and we can make sure it flushes several times per second into HBase by
> tuning the buffer size.
> We also have situations where the event rate is unpredictable. Some times
> because the source is in reality a batch job that puts records into Kafka,
> sometimes because it is the "predictable in production" application in our
> testing environment (where only the dev triggers a handful of events).
> For these kinds of use cases we need a way to 'force' the BufferedMutator to
> automatically flush any records in the buffer even if the buffer is not full.
> I'll put up a pull request with a proposed implementation for review against
> the master (i.e. 3.0.0).
> When approved I would like to backport this to the 1.x and 2.x versions of
> the client in the same (as close as possible) way.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19358) Improve the stability of splitting log when do fail over
[
https://issues.apache.org/jira/browse/HBASE-19358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306209#comment-16306209
]
Hadoop QA commented on HBASE-19358:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
12s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color: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 2 new or modified test
files. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
13s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
38s{color} | {color:green} branch-1 passed with JDK v1.8.0_152 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
39s{color} | {color:green} branch-1 passed with JDK v1.7.0_161 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
18s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
55s{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
12s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} branch-1 passed with JDK v1.8.0_152 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
35s{color} | {color:green} branch-1 passed with JDK v1.7.0_161 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
39s{color} | {color:green} the patch passed with JDK v1.8.0_152 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
39s{color} | {color:green} the patch passed with JDK v1.7.0_161 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
39s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
18s{color} | {color:red} hbase-server: The patch generated 5 new + 67 unchanged
- 2 fixed = 72 total (was 69) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
37s{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 19s{color} | {color:green} Patch does not cause any errors with Hadoop
2.4.1 2.5.2 2.6.5 2.7.4. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m
34s{color} | {color:red} hbase-server generated 1 new + 0 unchanged - 0 fixed =
1 total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
27s{color} | {color:green} the patch passed with JDK v1.8.0_152 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} the patch passed with JDK v1.7.0_161 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}101m 8s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
18s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}131m 20s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | Invocation of toString on WALSplitter$RegionEntryBuffer.encodedRegionName
in
org.apache.hadoop.hbase.wal.WALSplitter$BoundedLogWriterCreationOutputSink.executeCloseTask(CompletionService,
List, List) At WALSplitter.java:in
org.apache.h
[jira] [Commented] (HBASE-19662) hbase-metrics-api fails checkstyle due to wrong import order
[
https://issues.apache.org/jira/browse/HBASE-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306212#comment-16306212
]
Chia-Ping Tsai commented on HBASE-19662:
I run the same commend for hbase-metrics-api.
{code}
grep ImportOrderCheck hbase-metrics-api/target/checkstyle-result.xml | wc
0 0 0
{code}
The commit of HBASE-19552 are divided into 2 parts. If you build hbase on top
of ea7d5fc88454cc8d623d837e2d8975643e354bda, you will encounter the build
error. I believe the error is gone now.
{quote}
Maybe we should temporarily disable the import order rule.
What do you think ?
{quote}
I prefer to resolved all checkstyle issuesya, a difficult job. There is a
related issue. HBASE-12521.
> hbase-metrics-api fails checkstyle due to wrong import order
>
>
> Key: HBASE-19662
> URL: https://issues.apache.org/jira/browse/HBASE-19662
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Minor
> Attachments: 19662.v1.txt
>
>
> In recent trunk builds, there were the following errors:
> {code}
> [ERROR]
> src/main/java/org/apache/hadoop/hbase/metrics/MetricRegistriesLoader.java:[31]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.annotations.VisibleForTesting'
> import.
> [ERROR]
> src/test/java/org/apache/hadoop/hbase/metrics/TestMetricRegistriesLoader.java:[28]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.collect.Lists' import.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19663) site build fails complaining "javadoc: error - class file for javax.annotation.meta.TypeQualifierNickname not found"
[
https://issues.apache.org/jira/browse/HBASE-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306215#comment-16306215
]
stack commented on HBASE-19663:
---
alpha-4 javadoc builds fine. I thought it checkstyle since it has jsr305
dependency... but attempts at parsing it out or excluding jsr doesn't seem to
cut it. Trying bisect now.
> site build fails complaining "javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found"
>
>
> Key: HBASE-19663
> URL: https://issues.apache.org/jira/browse/HBASE-19663
> Project: HBase
> Issue Type: Bug
> Components: site
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0-beta-1
>
>
> Cryptic failure trying to build beta-1 RC. Fails like this:
> {code}
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 03:54 min
> [INFO] Finished at: 2017-12-29T01:13:15-08:00
> [INFO] Final Memory: 381M/9165M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
> hbase: Error generating maven-javadoc-plugin:2.10.3:aggregate:
> [ERROR] Exit code: 1 - warning: unknown enum constant When.ALWAYS
> [ERROR] reason: class file for javax.annotation.meta.When not found
> [ERROR] warning: unknown enum constant When.UNKNOWN
> [ERROR] warning: unknown enum constant When.MAYBE
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: malformed: "#matchingRows(Cell, byte[]))"
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR] javadoc: warning - Class javax.annotation.Nonnull not found.
> [ERROR] javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found
> [ERROR]
> [ERROR] Command line was: /home/stack/bin/jdk1.8.0_151/jre/../bin/javadoc
> -J-Xmx2G @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/stack/hbase.git/target/site/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}
> javax.annotation.meta.TypeQualifierNickname is out of jsr305 but we don't
> include this anywhere according to mvn dependency.
> Happens building the User API both test and main.
> Excluding these lines gets us passing again:
> {code}
> 3511
> 3512
> org.apache.yetus.audience.tools.IncludePublicAnnotationsStandardDoclet
> 3513
> 3514
> 3515 org.apache.yetus
> 3516 audience-annotations
> 3517 ${audience-annotations.version}
> 3518
> + 3519 true
> {code}
> Tried upgrading to newer mvn site (ours is three years old) but that a
> different set of problems.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19622) Reimplement ReplicationPeers with the new replication storage interface
[
https://issues.apache.org/jira/browse/HBASE-19622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306224#comment-16306224
]
Hadoop QA commented on HBASE-19622:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
9s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
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 8 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-19397 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
10s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
36s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
48s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
11s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
51s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
22s{color} | {color:green} HBASE-19397 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
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
30s{color} | {color:green} The patch hbase-client passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
12s{color} | {color:green} The patch hbase-zookeeper passed checkstyle {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
12s{color} | {color:red} hbase-replication: The patch generated 1 new + 3
unchanged - 6 fixed = 4 total (was 9) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
3s{color} | {color:green} hbase-server: The patch generated 0 new + 41
unchanged - 3 fixed = 41 total (was 44) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
16s{color} | {color:green} The patch hbase-mapreduce 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
40s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 2s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
28s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
44s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
36s{color} | {color:green} hbase-zookeeper in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
17s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}114m 41s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 10m
5s{color} | {color:green} hbase-mapreduce in t
[jira] [Commented] (HBASE-19500) Make RSGroupInfo immutable
[
https://issues.apache.org/jira/browse/HBASE-19500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306225#comment-16306225
]
Chia-Ping Tsai commented on HBASE-19500:
bq. you can take up the check removal?
HBASE-19667
> Make RSGroupInfo immutable
> --
>
> Key: HBASE-19500
> URL: https://issues.apache.org/jira/browse/HBASE-19500
> Project: HBase
> Issue Type: Bug
>Reporter: Appy
>
> HBASE-19483 added CP hooks to expose RSGroupInfo.
> First, we should at least change [hbase-client] RSGroupInfo to immutable +
> builder pattern like we have done for so many other things.
> What say [~Apache9]
> Then, few questions need figuring out:
> - Should hooks be allowed to change RSGroupInfo.
> Probably not? Then making it immutable would be necessary and sufficient
> - Can we remove {{if(((MasterEnvironment)getEnvironment()).supportGroupCPs)
> }} in so many places since CP in 2.0 are already broken left and right (and
> we'll have to solve legacy issue more holistically) What say [~anoop.hbase]?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19667) gir rid of MasterEnvironment#supportGroupCPs
Chia-Ping Tsai created HBASE-19667:
--
Summary: gir rid of MasterEnvironment#supportGroupCPs
Key: HBASE-19667
URL: https://issues.apache.org/jira/browse/HBASE-19667
Project: HBase
Issue Type: Sub-task
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
copy the discussion from HBASE-19500.
{quote}
Appy:
Can we remove {{if(((MasterEnvironment)getEnvironment()).supportGroupCPs) }} in
so many places since CP in 2.0 are already broken left and right (and we'll
have to solve legacy issue more holistically) What say Anoop Sam John?
Chia:
The cp user must do something to migrate their cp code from 1.x to 2.0 anyway,
hence the check is unnecessary in 2.0 I'd say. Seems it is unrelated to this
jira. Iron out it in another jira?
Appy:
Chia-Ping Tsai you can take up the check removal?
{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19667) gir rid of MasterEnvironment#supportGroupCPs
[
https://issues.apache.org/jira/browse/HBASE-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19667:
---
Component/s: Coprocessors
> gir rid of MasterEnvironment#supportGroupCPs
>
>
> Key: HBASE-19667
> URL: https://issues.apache.org/jira/browse/HBASE-19667
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-2
>
>
> copy the discussion from HBASE-19500.
> {quote}
> Appy:
> Can we remove {{if(((MasterEnvironment)getEnvironment()).supportGroupCPs) }}
> in so many places since CP in 2.0 are already broken left and right (and
> we'll have to solve legacy issue more holistically) What say Anoop Sam John?
> Chia:
> The cp user must do something to migrate their cp code from 1.x to 2.0
> anyway, hence the check is unnecessary in 2.0 I'd say. Seems it is unrelated
> to this jira. Iron out it in another jira?
> Appy:
> Chia-Ping Tsai you can take up the check removal?
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19667) gir rid of MasterEnvironment#supportGroupCPs
[
https://issues.apache.org/jira/browse/HBASE-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19667:
---
Fix Version/s: 2.0.0-beta-2
> gir rid of MasterEnvironment#supportGroupCPs
>
>
> Key: HBASE-19667
> URL: https://issues.apache.org/jira/browse/HBASE-19667
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-2
>
>
> copy the discussion from HBASE-19500.
> {quote}
> Appy:
> Can we remove {{if(((MasterEnvironment)getEnvironment()).supportGroupCPs) }}
> in so many places since CP in 2.0 are already broken left and right (and
> we'll have to solve legacy issue more holistically) What say Anoop Sam John?
> Chia:
> The cp user must do something to migrate their cp code from 1.x to 2.0
> anyway, hence the check is unnecessary in 2.0 I'd say. Seems it is unrelated
> to this jira. Iron out it in another jira?
> Appy:
> Chia-Ping Tsai you can take up the check removal?
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19622) Reimplement ReplicationPeers with the new replication storage interface
[
https://issues.apache.org/jira/browse/HBASE-19622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306230#comment-16306230
]
Hadoop QA commented on HBASE-19622:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
10s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 8 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-19397 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
59s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
1s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
15s{color} | {color:green} HBASE-19397 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 7m
8s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
31s{color} | {color:green} HBASE-19397 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
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
31s{color} | {color:green} The patch hbase-client passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
14s{color} | {color:green} The patch hbase-zookeeper passed checkstyle {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
11s{color} | {color:red} hbase-replication: The patch generated 1 new + 3
unchanged - 6 fixed = 4 total (was 9) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
6s{color} | {color:green} hbase-server: The patch generated 0 new + 41
unchanged - 3 fixed = 41 total (was 44) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
20s{color} | {color:green} The patch hbase-mapreduce 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
50s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 16s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
28s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
43s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
37s{color} | {color:green} hbase-zookeeper in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
17s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}100m 4s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 10m
32s{color} | {color:green} hbase-mapreduce in t
[jira] [Updated] (HBASE-19428) Deprecate the compareTo(Row)
[ https://issues.apache.org/jira/browse/HBASE-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19428: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Thanks for the reviews. [~stack] > Deprecate the compareTo(Row) > > > Key: HBASE-19428 > URL: https://issues.apache.org/jira/browse/HBASE-19428 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19428.v0.patch > > > Sorting the Put/Delete/Increment/Append by row is weird and not > straightforward. We should explicitly have a Row sorter and deprecate the > compareTo(Row) in Put/Delete/Increment/Append. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19667) Get rid of MasterEnvironment#supportGroupCPs
[
https://issues.apache.org/jira/browse/HBASE-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19667:
---
Summary: Get rid of MasterEnvironment#supportGroupCPs (was: gir rid of
MasterEnvironment#supportGroupCPs)
> Get rid of MasterEnvironment#supportGroupCPs
>
>
> Key: HBASE-19667
> URL: https://issues.apache.org/jira/browse/HBASE-19667
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-2
>
>
> copy the discussion from HBASE-19500.
> {quote}
> Appy:
> Can we remove {{if(((MasterEnvironment)getEnvironment()).supportGroupCPs) }}
> in so many places since CP in 2.0 are already broken left and right (and
> we'll have to solve legacy issue more holistically) What say Anoop Sam John?
> Chia:
> The cp user must do something to migrate their cp code from 1.x to 2.0
> anyway, hence the check is unnecessary in 2.0 I'd say. Seems it is unrelated
> to this jira. Iron out it in another jira?
> Appy:
> Chia-Ping Tsai you can take up the check removal?
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (HBASE-19425) Align the methods in Put/Delete/Increment/Append
[ https://issues.apache.org/jira/browse/HBASE-19425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved HBASE-19425. Resolution: Fixed All tasks are done. > Align the methods in Put/Delete/Increment/Append > > > Key: HBASE-19425 > URL: https://issues.apache.org/jira/browse/HBASE-19425 > Project: HBase > Issue Type: Umbrella >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19666) hadoop.hbase.regionserver.TestDefaultCompactSelection test failed
[
https://issues.apache.org/jira/browse/HBASE-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306234#comment-16306234
]
Jingyun Tian commented on HBASE-19666:
--
test of TestDefaultCompactSelection$testCompactionRatio() has code like this:
{code}
this.conf.setLong("hbase.hstore.compaction.min.size", 1);
store.storeEngine.getCompactionPolicy().setConf(conf);
compactEquals(sfCreate(512,256,128,64,32,16,8,4,2,1), 4,2,1);
{code}
that set the hbase.hstore.compaction.min.size to 1, and when we filter files to
do compaction, there is a check:
{code}
if (size >= comConf.getMinCompactSize()
&& !filesInRatio(potentialMatchFiles, currentRatio)) {
continue;
}
{code}
Since the smallest file is 1, there is no possible that size could smaller than
comConf.getMinCompactSize().
For check of filesInRatio, there is a constraint that single file size should
small than sum of other files. But for the file combinations of
512,256,128,64,32,16,8,4,2,1, the single file size always bigger than the sum
of rest files.
> hadoop.hbase.regionserver.TestDefaultCompactSelection test failed
> -
>
> Key: HBASE-19666
> URL: https://issues.apache.org/jira/browse/HBASE-19666
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Jingyun Tian
>Priority: Critical
>
> hadoop.hbase.regionserver.TestDefaultCompactSelection
> [ERROR] Failures:
> [ERROR]
> TestDefaultCompactSelection.testCompactionRatio:74->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201
> expected:<[[4, 2, 1]]> but was:<[[]]>
> [ERROR]
> TestDefaultCompactSelection.testStuckStoreCompaction:145->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201
> expected:<[[]30, 30, 30]> but was:<[[99, 30, ]30, 30, 30]>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-8518) Get rid of hbase.hstore.compaction.complete setting
[
https://issues.apache.org/jira/browse/HBASE-8518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306246#comment-16306246
]
Chia-Ping Tsai commented on HBASE-8518:
---
Remove the {{VisibleForTesting}} from the test files.
{code}
+ @InterfaceAudience.Private
+ @VisibleForTesting
+ public static class HStoreForTesting extends HStore {
{code}
Remove the unused docs.
{code}
+/**
+ * Constructor
+ * @param region
+ * @param family
+ * @param confParam
+ * @throws IOException
+ */
+@VisibleForTesting
{code}
Otherwise LGTM
> Get rid of hbase.hstore.compaction.complete setting
> ---
>
> Key: HBASE-8518
> URL: https://issues.apache.org/jira/browse/HBASE-8518
> Project: HBase
> Issue Type: Improvement
>Reporter: Sergey Shelukhin
>Assignee: Kuan-Po Tseng
>Priority: Minor
> Labels: beginner
> Attachments: HBASE-8518-1.patch, HBASE-8518.master.v0.patch,
> HBASE-8518.master.v1.patch, HBASE-8518.master.v2.patch, HBASE-8518.wip.patch
>
>
> hbase.hstore.compaction.complete is a strange setting that causes the
> finished compaction to not complete (files are just left in tmp) in HStore.
> It's used by one test.
> The setting with the same name is also used by CompactionTool, but that usage
> is semi-unrelated and could probably be removed easily.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19666) hadoop.hbase.regionserver.TestDefaultCompactSelection test failed
[ https://issues.apache.org/jira/browse/HBASE-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306261#comment-16306261 ] Ted Yu commented on HBASE-19666: Which branch did you observe the test failure ? If it was from Jenkins, can you post the link to the test output ? > hadoop.hbase.regionserver.TestDefaultCompactSelection test failed > - > > Key: HBASE-19666 > URL: https://issues.apache.org/jira/browse/HBASE-19666 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Jingyun Tian >Priority: Critical > > hadoop.hbase.regionserver.TestDefaultCompactSelection > [ERROR] Failures: > [ERROR] > TestDefaultCompactSelection.testCompactionRatio:74->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 > expected:<[[4, 2, 1]]> but was:<[[]]> > [ERROR] > TestDefaultCompactSelection.testStuckStoreCompaction:145->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 > expected:<[[]30, 30, 30]> but was:<[[99, 30, ]30, 30, 30]> -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19662) hbase-metrics-api fails checkstyle due to wrong import order
[
https://issues.apache.org/jira/browse/HBASE-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306263#comment-16306263
]
Ted Yu commented on HBASE-19662:
See
https://builds.apache.org/job/HBase-TRUNK_matrix/jdk=JDK%201.8%20(latest),label=(Hadoop%20&&%20!H5)/4305/
which was based on 8d0da1a77f50b730b366c28b5b477141aa83cc55
The error was still there.
> hbase-metrics-api fails checkstyle due to wrong import order
>
>
> Key: HBASE-19662
> URL: https://issues.apache.org/jira/browse/HBASE-19662
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Minor
> Attachments: 19662.v1.txt
>
>
> In recent trunk builds, there were the following errors:
> {code}
> [ERROR]
> src/main/java/org/apache/hadoop/hbase/metrics/MetricRegistriesLoader.java:[31]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.annotations.VisibleForTesting'
> import.
> [ERROR]
> src/test/java/org/apache/hadoop/hbase/metrics/TestMetricRegistriesLoader.java:[28]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.collect.Lists' import.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19483) Add proper privilege check for rsgroup commands
[ https://issues.apache.org/jira/browse/HBASE-19483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306265#comment-16306265 ] Ted Yu commented on HBASE-19483: [~appy]: Mind taking another look ? > Add proper privilege check for rsgroup commands > --- > > Key: HBASE-19483 > URL: https://issues.apache.org/jira/browse/HBASE-19483 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Guangxu Cheng > Fix For: 1.4.1, 1.5.0, 2.0.0-beta-2 > > Attachments: 19483.master.011.patch, 19483.v11.patch, > 19483.v11.patch, HBASE-19483.master.001.patch, HBASE-19483.master.002.patch, > HBASE-19483.master.003.patch, HBASE-19483.master.004.patch, > HBASE-19483.master.005.patch, HBASE-19483.master.006.patch, > HBASE-19483.master.007.patch, HBASE-19483.master.008.patch, > HBASE-19483.master.009.patch, HBASE-19483.master.010.patch, > HBASE-19483.master.011.patch, HBASE-19483.master.011.patch > > > Currently list_rsgroups command can be executed by any user. > This is inconsistent with other list commands such as list_peers and > list_peer_configs. > We should add proper privilege check for list_rsgroups command. > privilege check should be added for get_table_rsgroup / get_server_rsgroup / > get_rsgroup commands. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19486) Periodically ensure records are not buffered too long by BufferedMutator
[ https://issues.apache.org/jira/browse/HBASE-19486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niels Basjes updated HBASE-19486: - Attachment: HBASE-19486-branch-1.v0.patch The backport of the patch to branch-1. I have tried to keep this set of changes "as close as possible" to the original patch against master. Most notable differences # because of Java 1.7 the interface cannot have default implementations. # I have also included a few parts (mostly tests) from the master branch to test everything in an as similar as possible way. > Periodically ensure records are not buffered too long by BufferedMutator > - > > Key: HBASE-19486 > URL: https://issues.apache.org/jira/browse/HBASE-19486 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Niels Basjes >Assignee: Niels Basjes > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19486-20171212-2117.patch, > HBASE-19486-20171218-1229.patch, HBASE-19486-20171218-1300.patch, > HBASE-19486-20171219-0933.patch, HBASE-19486-20171219-1026.patch, > HBASE-19486-20171219-1122-trigger-qa-run.patch, > HBASE-19486-20171220-1612-trigger-qa-run.patch, > HBASE-19486-20171220-2228-trigger-qa-run.patch, > HBASE-19486-20171223-1438-trigger-qa-run.patch, > HBASE-19486-20171223-1728-trigger-qa-run.patch, > HBASE-19486-20171223--trigger-qa-run.patch, > HBASE-19486-20171224-1101-trigger-qa-run.patch, > HBASE-19486-20171224-1602.patch, HBASE-19486-branch-1.v0.patch, > HBASE-19486.v0.patch > > > I'm working on several projects where we are doing stream / event type > processing instead of batch type processing. We mostly use Apache Flink and > Apache Beam for these projects. > When we ingest a continuous stream of events and feed that into HBase via a > BufferedMutator this all works fine. The buffer fills up at a predictable > rate and we can make sure it flushes several times per second into HBase by > tuning the buffer size. > We also have situations where the event rate is unpredictable. Some times > because the source is in reality a batch job that puts records into Kafka, > sometimes because it is the "predictable in production" application in our > testing environment (where only the dev triggers a handful of events). > For these kinds of use cases we need a way to 'force' the BufferedMutator to > automatically flush any records in the buffer even if the buffer is not full. > I'll put up a pull request with a proposed implementation for review against > the master (i.e. 3.0.0). > When approved I would like to backport this to the 1.x and 2.x versions of > the client in the same (as close as possible) way. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19486) Periodically ensure records are not buffered too long by BufferedMutator
[
https://issues.apache.org/jira/browse/HBASE-19486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306268#comment-16306268
]
Hadoop QA commented on HBASE-19486:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 6s{color}
| {color:red} HBASE-19486 does not apply to branch-1. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.6.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-19486 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12904010/HBASE-19486-branch-1.v0.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10789/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> Periodically ensure records are not buffered too long by BufferedMutator
> -
>
> Key: HBASE-19486
> URL: https://issues.apache.org/jira/browse/HBASE-19486
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Reporter: Niels Basjes
>Assignee: Niels Basjes
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19486-20171212-2117.patch,
> HBASE-19486-20171218-1229.patch, HBASE-19486-20171218-1300.patch,
> HBASE-19486-20171219-0933.patch, HBASE-19486-20171219-1026.patch,
> HBASE-19486-20171219-1122-trigger-qa-run.patch,
> HBASE-19486-20171220-1612-trigger-qa-run.patch,
> HBASE-19486-20171220-2228-trigger-qa-run.patch,
> HBASE-19486-20171223-1438-trigger-qa-run.patch,
> HBASE-19486-20171223-1728-trigger-qa-run.patch,
> HBASE-19486-20171223--trigger-qa-run.patch,
> HBASE-19486-20171224-1101-trigger-qa-run.patch,
> HBASE-19486-20171224-1602.patch, HBASE-19486-branch-1.v0.patch,
> HBASE-19486.v0.patch
>
>
> I'm working on several projects where we are doing stream / event type
> processing instead of batch type processing. We mostly use Apache Flink and
> Apache Beam for these projects.
> When we ingest a continuous stream of events and feed that into HBase via a
> BufferedMutator this all works fine. The buffer fills up at a predictable
> rate and we can make sure it flushes several times per second into HBase by
> tuning the buffer size.
> We also have situations where the event rate is unpredictable. Some times
> because the source is in reality a batch job that puts records into Kafka,
> sometimes because it is the "predictable in production" application in our
> testing environment (where only the dev triggers a handful of events).
> For these kinds of use cases we need a way to 'force' the BufferedMutator to
> automatically flush any records in the buffer even if the buffer is not full.
> I'll put up a pull request with a proposed implementation for review against
> the master (i.e. 3.0.0).
> When approved I would like to backport this to the 1.x and 2.x versions of
> the client in the same (as close as possible) way.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19486) Periodically ensure records are not buffered too long by BufferedMutator
[ https://issues.apache.org/jira/browse/HBASE-19486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niels Basjes updated HBASE-19486: - Attachment: HBASE-19486-branch-1.v1.patch Rebased > Periodically ensure records are not buffered too long by BufferedMutator > - > > Key: HBASE-19486 > URL: https://issues.apache.org/jira/browse/HBASE-19486 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Niels Basjes >Assignee: Niels Basjes > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19486-20171212-2117.patch, > HBASE-19486-20171218-1229.patch, HBASE-19486-20171218-1300.patch, > HBASE-19486-20171219-0933.patch, HBASE-19486-20171219-1026.patch, > HBASE-19486-20171219-1122-trigger-qa-run.patch, > HBASE-19486-20171220-1612-trigger-qa-run.patch, > HBASE-19486-20171220-2228-trigger-qa-run.patch, > HBASE-19486-20171223-1438-trigger-qa-run.patch, > HBASE-19486-20171223-1728-trigger-qa-run.patch, > HBASE-19486-20171223--trigger-qa-run.patch, > HBASE-19486-20171224-1101-trigger-qa-run.patch, > HBASE-19486-20171224-1602.patch, HBASE-19486-branch-1.v0.patch, > HBASE-19486-branch-1.v1.patch, HBASE-19486.v0.patch > > > I'm working on several projects where we are doing stream / event type > processing instead of batch type processing. We mostly use Apache Flink and > Apache Beam for these projects. > When we ingest a continuous stream of events and feed that into HBase via a > BufferedMutator this all works fine. The buffer fills up at a predictable > rate and we can make sure it flushes several times per second into HBase by > tuning the buffer size. > We also have situations where the event rate is unpredictable. Some times > because the source is in reality a batch job that puts records into Kafka, > sometimes because it is the "predictable in production" application in our > testing environment (where only the dev triggers a handful of events). > For these kinds of use cases we need a way to 'force' the BufferedMutator to > automatically flush any records in the buffer even if the buffer is not full. > I'll put up a pull request with a proposed implementation for review against > the master (i.e. 3.0.0). > When approved I would like to backport this to the 1.x and 2.x versions of > the client in the same (as close as possible) way. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19428) Deprecate the compareTo(Row)
[ https://issues.apache.org/jira/browse/HBASE-19428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306284#comment-16306284 ] Hudson commented on HBASE-19428: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4306 (See [https://builds.apache.org/job/HBase-Trunk_matrix/4306/]) HBASE-19428 Deprecate the compareTo(Row) (chia7712: rev e23f7afe5791c248f1ccdf031788ffc6df2c263b) * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Increment.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Get.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Mutation.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/RowMutations.java * (add) hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestRowComparator.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Row.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/RegionCoprocessorServiceExec.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java > Deprecate the compareTo(Row) > > > Key: HBASE-19428 > URL: https://issues.apache.org/jira/browse/HBASE-19428 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19428.v0.patch > > > Sorting the Put/Delete/Increment/Append by row is weird and not > straightforward. We should explicitly have a Row sorter and deprecate the > compareTo(Row) in Put/Delete/Increment/Append. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19486) Periodically ensure records are not buffered too long by BufferedMutator
[
https://issues.apache.org/jira/browse/HBASE-19486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306286#comment-16306286
]
Hadoop QA commented on HBASE-19486:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} docker {color} | {color:red} 13m
26s{color} | {color:red} Docker failed to build yetus/hbase:36a7029. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-19486 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12904011/HBASE-19486-branch-1.v1.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10790/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> Periodically ensure records are not buffered too long by BufferedMutator
> -
>
> Key: HBASE-19486
> URL: https://issues.apache.org/jira/browse/HBASE-19486
> Project: HBase
> Issue Type: Improvement
> Components: Client
>Reporter: Niels Basjes
>Assignee: Niels Basjes
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19486-20171212-2117.patch,
> HBASE-19486-20171218-1229.patch, HBASE-19486-20171218-1300.patch,
> HBASE-19486-20171219-0933.patch, HBASE-19486-20171219-1026.patch,
> HBASE-19486-20171219-1122-trigger-qa-run.patch,
> HBASE-19486-20171220-1612-trigger-qa-run.patch,
> HBASE-19486-20171220-2228-trigger-qa-run.patch,
> HBASE-19486-20171223-1438-trigger-qa-run.patch,
> HBASE-19486-20171223-1728-trigger-qa-run.patch,
> HBASE-19486-20171223--trigger-qa-run.patch,
> HBASE-19486-20171224-1101-trigger-qa-run.patch,
> HBASE-19486-20171224-1602.patch, HBASE-19486-branch-1.v0.patch,
> HBASE-19486-branch-1.v1.patch, HBASE-19486.v0.patch
>
>
> I'm working on several projects where we are doing stream / event type
> processing instead of batch type processing. We mostly use Apache Flink and
> Apache Beam for these projects.
> When we ingest a continuous stream of events and feed that into HBase via a
> BufferedMutator this all works fine. The buffer fills up at a predictable
> rate and we can make sure it flushes several times per second into HBase by
> tuning the buffer size.
> We also have situations where the event rate is unpredictable. Some times
> because the source is in reality a batch job that puts records into Kafka,
> sometimes because it is the "predictable in production" application in our
> testing environment (where only the dev triggers a handful of events).
> For these kinds of use cases we need a way to 'force' the BufferedMutator to
> automatically flush any records in the buffer even if the buffer is not full.
> I'll put up a pull request with a proposed implementation for review against
> the master (i.e. 3.0.0).
> When approved I would like to backport this to the 1.x and 2.x versions of
> the client in the same (as close as possible) way.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19486) Periodically ensure records are not buffered too long by BufferedMutator
[ https://issues.apache.org/jira/browse/HBASE-19486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306301#comment-16306301 ] Chia-Ping Tsai commented on HBASE-19486: bq. because of Java 1.7 the interface cannot have default implementations. Seems it break our BC if we backport this feature to branch-1. Let me commit it to master and branch-2. We can open another issue to discuss how to backport this feature to branch-1 without breaking the BC. > Periodically ensure records are not buffered too long by BufferedMutator > - > > Key: HBASE-19486 > URL: https://issues.apache.org/jira/browse/HBASE-19486 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Niels Basjes >Assignee: Niels Basjes > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19486-20171212-2117.patch, > HBASE-19486-20171218-1229.patch, HBASE-19486-20171218-1300.patch, > HBASE-19486-20171219-0933.patch, HBASE-19486-20171219-1026.patch, > HBASE-19486-20171219-1122-trigger-qa-run.patch, > HBASE-19486-20171220-1612-trigger-qa-run.patch, > HBASE-19486-20171220-2228-trigger-qa-run.patch, > HBASE-19486-20171223-1438-trigger-qa-run.patch, > HBASE-19486-20171223-1728-trigger-qa-run.patch, > HBASE-19486-20171223--trigger-qa-run.patch, > HBASE-19486-20171224-1101-trigger-qa-run.patch, > HBASE-19486-20171224-1602.patch, HBASE-19486-branch-1.v0.patch, > HBASE-19486-branch-1.v1.patch, HBASE-19486.v0.patch > > > I'm working on several projects where we are doing stream / event type > processing instead of batch type processing. We mostly use Apache Flink and > Apache Beam for these projects. > When we ingest a continuous stream of events and feed that into HBase via a > BufferedMutator this all works fine. The buffer fills up at a predictable > rate and we can make sure it flushes several times per second into HBase by > tuning the buffer size. > We also have situations where the event rate is unpredictable. Some times > because the source is in reality a batch job that puts records into Kafka, > sometimes because it is the "predictable in production" application in our > testing environment (where only the dev triggers a handful of events). > For these kinds of use cases we need a way to 'force' the BufferedMutator to > automatically flush any records in the buffer even if the buffer is not full. > I'll put up a pull request with a proposed implementation for review against > the master (i.e. 3.0.0). > When approved I would like to backport this to the 1.x and 2.x versions of > the client in the same (as close as possible) way. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19486) Periodically ensure records are not buffered too long by BufferedMutator
[ https://issues.apache.org/jira/browse/HBASE-19486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19486: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Thanks for the nice feature. [~nielsbasjes] > Periodically ensure records are not buffered too long by BufferedMutator > - > > Key: HBASE-19486 > URL: https://issues.apache.org/jira/browse/HBASE-19486 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Niels Basjes >Assignee: Niels Basjes > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19486-20171212-2117.patch, > HBASE-19486-20171218-1229.patch, HBASE-19486-20171218-1300.patch, > HBASE-19486-20171219-0933.patch, HBASE-19486-20171219-1026.patch, > HBASE-19486-20171219-1122-trigger-qa-run.patch, > HBASE-19486-20171220-1612-trigger-qa-run.patch, > HBASE-19486-20171220-2228-trigger-qa-run.patch, > HBASE-19486-20171223-1438-trigger-qa-run.patch, > HBASE-19486-20171223-1728-trigger-qa-run.patch, > HBASE-19486-20171223--trigger-qa-run.patch, > HBASE-19486-20171224-1101-trigger-qa-run.patch, > HBASE-19486-20171224-1602.patch, HBASE-19486-branch-1.v0.patch, > HBASE-19486-branch-1.v1.patch, HBASE-19486.v0.patch > > > I'm working on several projects where we are doing stream / event type > processing instead of batch type processing. We mostly use Apache Flink and > Apache Beam for these projects. > When we ingest a continuous stream of events and feed that into HBase via a > BufferedMutator this all works fine. The buffer fills up at a predictable > rate and we can make sure it flushes several times per second into HBase by > tuning the buffer size. > We also have situations where the event rate is unpredictable. Some times > because the source is in reality a batch job that puts records into Kafka, > sometimes because it is the "predictable in production" application in our > testing environment (where only the dev triggers a handful of events). > For these kinds of use cases we need a way to 'force' the BufferedMutator to > automatically flush any records in the buffer even if the buffer is not full. > I'll put up a pull request with a proposed implementation for review against > the master (i.e. 3.0.0). > When approved I would like to backport this to the 1.x and 2.x versions of > the client in the same (as close as possible) way. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-8518) Get rid of hbase.hstore.compaction.complete setting
[ https://issues.apache.org/jira/browse/HBASE-8518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kuan-Po Tseng updated HBASE-8518: - Attachment: HBASE-8518.master.v3.patch All done. Thanks for your comments. > Get rid of hbase.hstore.compaction.complete setting > --- > > Key: HBASE-8518 > URL: https://issues.apache.org/jira/browse/HBASE-8518 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Kuan-Po Tseng >Priority: Minor > Labels: beginner > Attachments: HBASE-8518-1.patch, HBASE-8518.master.v0.patch, > HBASE-8518.master.v1.patch, HBASE-8518.master.v2.patch, > HBASE-8518.master.v3.patch, HBASE-8518.wip.patch > > > hbase.hstore.compaction.complete is a strange setting that causes the > finished compaction to not complete (files are just left in tmp) in HStore. > It's used by one test. > The setting with the same name is also used by CompactionTool, but that usage > is semi-unrelated and could probably be removed easily. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19359) Revisit the default config of hbase client retries number
[ https://issues.apache.org/jira/browse/HBASE-19359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306334#comment-16306334 ] Dave Latham commented on HBASE-19359: - As someone who has used these configs before, and reading this discussion again, it reminds me that the ways these configs are setup is not the simplest or most intuitive for a user. In particular, most users would probably prefer to configure some max timeout in milliseconds, rather than spend time deciphering the backoff schedule and working out how many retries that needs to be. > Revisit the default config of hbase client retries number > - > > Key: HBASE-19359 > URL: https://issues.apache.org/jira/browse/HBASE-19359 > Project: HBase > Issue Type: Sub-task >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19359.master.001.patch, > HBASE-19359.master.001.patch, HBASE-19359.master.001.patch > > > This should be sub-task of HBASE-19148. As the retries number effect too many > unit tests. So I open this issue to see the Hadoop QA result. > The default value of hbase.client.retries.number is 35. Plan to reduce this > to 10. > And for server side, the default hbase.client.serverside.retries.multiplier > is 10. So the server side retries number is 35 * 10 = 350. It is too big! > Plan to reduce hbase.client.serverside.retries.multiplier to 3. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-8518) Get rid of hbase.hstore.compaction.complete setting
[
https://issues.apache.org/jira/browse/HBASE-8518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306340#comment-16306340
]
Mike Drob commented on HBASE-8518:
--
{code}
+/**
+ * If CF isn't MobEnabled, return HStoreForTesting.
+ * @param family
+ * @return HStoreForTesting, a HStore for testing.
+ * @throws IOException
+ */
+@Override
+protected HStore instantiateHStore(final ColumnFamilyDescriptor family)
throws IOException {
{code}
nit: remove or add docs on family and throws, please.
> Get rid of hbase.hstore.compaction.complete setting
> ---
>
> Key: HBASE-8518
> URL: https://issues.apache.org/jira/browse/HBASE-8518
> Project: HBase
> Issue Type: Improvement
>Reporter: Sergey Shelukhin
>Assignee: Kuan-Po Tseng
>Priority: Minor
> Labels: beginner
> Attachments: HBASE-8518-1.patch, HBASE-8518.master.v0.patch,
> HBASE-8518.master.v1.patch, HBASE-8518.master.v2.patch,
> HBASE-8518.master.v3.patch, HBASE-8518.wip.patch
>
>
> hbase.hstore.compaction.complete is a strange setting that causes the
> finished compaction to not complete (files are just left in tmp) in HStore.
> It's used by one test.
> The setting with the same name is also used by CompactionTool, but that usage
> is semi-unrelated and could probably be removed easily.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19359) Revisit the default config of hbase client retries number
[ https://issues.apache.org/jira/browse/HBASE-19359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306344#comment-16306344 ] stack commented on HBASE-19359: --- [~davelatham] yes. We didn't do this for hbase-2.0.0: https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9iEu_ktczrlKHK8N4SZzs/edit#heading=h.sgpibvbclz25 Maybe we'll get to it yet. > Revisit the default config of hbase client retries number > - > > Key: HBASE-19359 > URL: https://issues.apache.org/jira/browse/HBASE-19359 > Project: HBase > Issue Type: Sub-task >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19359.master.001.patch, > HBASE-19359.master.001.patch, HBASE-19359.master.001.patch > > > This should be sub-task of HBASE-19148. As the retries number effect too many > unit tests. So I open this issue to see the Hadoop QA result. > The default value of hbase.client.retries.number is 35. Plan to reduce this > to 10. > And for server side, the default hbase.client.serverside.retries.multiplier > is 10. So the server side retries number is 35 * 10 = 350. It is too big! > Plan to reduce hbase.client.serverside.retries.multiplier to 3. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19662) hbase-metrics-api fails checkstyle due to wrong import order
[
https://issues.apache.org/jira/browse/HBASE-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306346#comment-16306346
]
Mike Drob commented on HBASE-19662:
---
That is a very confusing error. Like [~chia7712], I also do not get that error
running locally.
[~tedyu] - can you reproduce it outside of the jenkins env? Maybe it is a
problem with our build job.
> hbase-metrics-api fails checkstyle due to wrong import order
>
>
> Key: HBASE-19662
> URL: https://issues.apache.org/jira/browse/HBASE-19662
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Minor
> Attachments: 19662.v1.txt
>
>
> In recent trunk builds, there were the following errors:
> {code}
> [ERROR]
> src/main/java/org/apache/hadoop/hbase/metrics/MetricRegistriesLoader.java:[31]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.annotations.VisibleForTesting'
> import.
> [ERROR]
> src/test/java/org/apache/hadoop/hbase/metrics/TestMetricRegistriesLoader.java:[28]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.collect.Lists' import.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19662) hbase-metrics-api fails checkstyle due to wrong import order
[
https://issues.apache.org/jira/browse/HBASE-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306351#comment-16306351
]
Mike Drob commented on HBASE-19662:
---
Oh, interesting, I get this error locally when running {{mvn site}}! That's
some kind of progress.
> hbase-metrics-api fails checkstyle due to wrong import order
>
>
> Key: HBASE-19662
> URL: https://issues.apache.org/jira/browse/HBASE-19662
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Minor
> Attachments: 19662.v1.txt
>
>
> In recent trunk builds, there were the following errors:
> {code}
> [ERROR]
> src/main/java/org/apache/hadoop/hbase/metrics/MetricRegistriesLoader.java:[31]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.annotations.VisibleForTesting'
> import.
> [ERROR]
> src/test/java/org/apache/hadoop/hbase/metrics/TestMetricRegistriesLoader.java:[28]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.collect.Lists' import.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19662) hbase-metrics-api fails checkstyle due to wrong import order
[
https://issues.apache.org/jira/browse/HBASE-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306354#comment-16306354
]
Mike Drob commented on HBASE-19662:
---
What I suspect is happening is that instead of using the current ruleset, that
job is downloading the old checkstyle jar from snapshots repo and using ruleset
from there (which hasn't been updated for new import order rules).
can somebody manually deploy the latest snapshot and see if that fixes things?
> hbase-metrics-api fails checkstyle due to wrong import order
>
>
> Key: HBASE-19662
> URL: https://issues.apache.org/jira/browse/HBASE-19662
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Minor
> Attachments: 19662.v1.txt
>
>
> In recent trunk builds, there were the following errors:
> {code}
> [ERROR]
> src/main/java/org/apache/hadoop/hbase/metrics/MetricRegistriesLoader.java:[31]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.annotations.VisibleForTesting'
> import.
> [ERROR]
> src/test/java/org/apache/hadoop/hbase/metrics/TestMetricRegistriesLoader.java:[28]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.collect.Lists' import.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19668) hbase1.3.1 (build hadoop2.7.4) shortcircuit problem
gehaijiang created HBASE-19668:
--
Summary: hbase1.3.1 (build hadoop2.7.4) shortcircuit problem
Key: HBASE-19668
URL: https://issues.apache.org/jira/browse/HBASE-19668
Project: HBase
Issue Type: Bug
Components: hbase
Affects Versions: 1.3.1
Environment: Online HBase services, large requests
hbase version: 1.3.1hadoop version: 2.7.4 os linux version: centos6.5
Reporter: gehaijiang
Online HBase services, large requests， hbase version: 1.3.1hadoop
version: 2.7.4 os linux version: centos6.5
hdfs-site.xml conf:
dfs.client.read.shortcircuit
true
hdfs-site.xml
dfs.domain.socket.path
/var/run/hadoop-hdfs/dn_socket
hdfs-site.xml
os linux command :netstat -an
unix 2 [ ACC ] STREAM LISTENING 10576083
/var/run/hadoop-hdfs/dn_socket
*{color:#d04437}problem :/var/run/hadoop-hdfs/dn_socket only one
LISTENING， but no CONNECTED {color}*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19669) hbase1.3.1 (build hadoop2.7.4) shortcircuit problem
gehaijiang created HBASE-19669:
--
Summary: hbase1.3.1 (build hadoop2.7.4) shortcircuit problem
Key: HBASE-19669
URL: https://issues.apache.org/jira/browse/HBASE-19669
Project: HBase
Issue Type: Bug
Components: hbase
Affects Versions: 1.3.1
Environment: Online HBase services, large requests
hbase version: 1.3.1hadoop version: 2.7.4 os linux version: centos6.5
Reporter: gehaijiang
Online HBase services, large requests， hbase version: 1.3.1hadoop
version: 2.7.4 os linux version: centos6.5
hdfs-site.xml conf:
dfs.client.read.shortcircuit
true
hdfs-site.xml
dfs.domain.socket.path
/var/run/hadoop-hdfs/dn_socket
hdfs-site.xml
os linux command :netstat -an
unix 2 [ ACC ] STREAM LISTENING 10576083
/var/run/hadoop-hdfs/dn_socket
*{color:#d04437}problem :/var/run/hadoop-hdfs/dn_socket only one
LISTENING， but no CONNECTED {color}*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19670) Workaround: Purge User API building from branch-2 so can make a beta-1
stack created HBASE-19670: - Summary: Workaround: Purge User API building from branch-2 so can make a beta-1 Key: HBASE-19670 URL: https://issues.apache.org/jira/browse/HBASE-19670 Project: HBase Issue Type: Sub-task Reporter: stack Entertaining idea of purging User API doc generation from branch-2 because am unable to figure why it broke (see parent issue). I don't want to hold up beta-1 for this. Filing placeholder issue against which I can hang testing this alternative. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19670) Workaround: Purge User API building from branch-2 so can make a beta-1
[ https://issues.apache.org/jira/browse/HBASE-19670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19670: -- Attachment: HBASE-19670.branch-2.001.patch > Workaround: Purge User API building from branch-2 so can make a beta-1 > -- > > Key: HBASE-19670 > URL: https://issues.apache.org/jira/browse/HBASE-19670 > Project: HBase > Issue Type: Sub-task > Components: site >Reporter: stack > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19670.branch-2.001.patch > > > Entertaining idea of purging User API doc generation from branch-2 because am > unable to figure why it broke (see parent issue). I don't want to hold up > beta-1 for this. Filing placeholder issue against which I can hang testing > this alternative. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19196) Release hbase-2.0.0-beta-1; the "Finish-line" release
[ https://issues.apache.org/jira/browse/HBASE-19196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306360#comment-16306360 ] stack commented on HBASE-19196: --- Still struggling with HBASE-19663. Committed HBASE-19670 which removes doclet filtering of User API based off yetus annotations (User API will be bloated -- to fix subsequently). Master does not seem to have this problem. Running git bisects in meantime but fragile and take forever. Made new tag 2.0.0-beta-1-RC0.2 which incorporates the HBASE-19670 workaround. Its at a46d4114b105b91cd5f2c5e3550b5238e4becc6e which includes the two more legit beta-1 commits since last night: commit e2f07aafb67a45dcf108cdbd437d7d1161f8d04c Author: Niels Basjes Date: Fri Dec 29 22:22:34 2017 +0800 HBASE-19486 Periodically ensure records are not buffered too long by BufferedMutator Signed-off-by: Chia-Ping Tsai commit 5612f2f692fa0d984eb8f7ba19a1ce2b63e4aecb Author: Chia-Ping Tsai Date: Fri Dec 29 20:03:39 2017 +0800 HBASE-19428 Deprecate the compareTo(Row) > Release hbase-2.0.0-beta-1; the "Finish-line" release > - > > Key: HBASE-19196 > URL: https://issues.apache.org/jira/browse/HBASE-19196 > Project: HBase > Issue Type: Bug >Reporter: stack >Priority: Blocker > Fix For: 2.0.0-beta-1 > > > APIs done, but external facing and Coprocessors. Done w/ features. Bug fixes > only from here on out. There'll be a beta-2 but that is about rolling upgrade > and bug fixes only. Then our first 2.0.0 Release Candidate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-19666) hadoop.hbase.regionserver.TestDefaultCompactSelection test failed
[ https://issues.apache.org/jira/browse/HBASE-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai reassigned HBASE-19666: -- Assignee: Chia-Ping Tsai > hadoop.hbase.regionserver.TestDefaultCompactSelection test failed > - > > Key: HBASE-19666 > URL: https://issues.apache.org/jira/browse/HBASE-19666 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0 >Reporter: Jingyun Tian >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0-beta-2 > > > hadoop.hbase.regionserver.TestDefaultCompactSelection > [ERROR] Failures: > [ERROR] > TestDefaultCompactSelection.testCompactionRatio:74->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 > expected:<[[4, 2, 1]]> but was:<[[]]> > [ERROR] > TestDefaultCompactSelection.testStuckStoreCompaction:145->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 > expected:<[[]30, 30, 30]> but was:<[[99, 30, ]30, 30, 30]> -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19666) hadoop.hbase.regionserver.TestDefaultCompactSelection test failed
[ https://issues.apache.org/jira/browse/HBASE-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306377#comment-16306377 ] Chia-Ping Tsai commented on HBASE-19666: It is caused by HBASE-19660 which change the threshold of blocking file. Will attach the path soon. > hadoop.hbase.regionserver.TestDefaultCompactSelection test failed > - > > Key: HBASE-19666 > URL: https://issues.apache.org/jira/browse/HBASE-19666 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0 >Reporter: Jingyun Tian >Priority: Critical > Fix For: 2.0.0-beta-2 > > > hadoop.hbase.regionserver.TestDefaultCompactSelection > [ERROR] Failures: > [ERROR] > TestDefaultCompactSelection.testCompactionRatio:74->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 > expected:<[[4, 2, 1]]> but was:<[[]]> > [ERROR] > TestDefaultCompactSelection.testStuckStoreCompaction:145->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 > expected:<[[]30, 30, 30]> but was:<[[99, 30, ]30, 30, 30]> -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19666) hadoop.hbase.regionserver.TestDefaultCompactSelection test failed
[ https://issues.apache.org/jira/browse/HBASE-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19666: --- Component/s: test > hadoop.hbase.regionserver.TestDefaultCompactSelection test failed > - > > Key: HBASE-19666 > URL: https://issues.apache.org/jira/browse/HBASE-19666 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0 >Reporter: Jingyun Tian >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0-beta-2 > > > hadoop.hbase.regionserver.TestDefaultCompactSelection > [ERROR] Failures: > [ERROR] > TestDefaultCompactSelection.testCompactionRatio:74->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 > expected:<[[4, 2, 1]]> but was:<[[]]> > [ERROR] > TestDefaultCompactSelection.testStuckStoreCompaction:145->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 > expected:<[[]30, 30, 30]> but was:<[[99, 30, ]30, 30, 30]> -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19666) hadoop.hbase.regionserver.TestDefaultCompactSelection test failed
[ https://issues.apache.org/jira/browse/HBASE-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19666: --- Fix Version/s: 2.0.0-beta-2 > hadoop.hbase.regionserver.TestDefaultCompactSelection test failed > - > > Key: HBASE-19666 > URL: https://issues.apache.org/jira/browse/HBASE-19666 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0 >Reporter: Jingyun Tian >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0-beta-2 > > > hadoop.hbase.regionserver.TestDefaultCompactSelection > [ERROR] Failures: > [ERROR] > TestDefaultCompactSelection.testCompactionRatio:74->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 > expected:<[[4, 2, 1]]> but was:<[[]]> > [ERROR] > TestDefaultCompactSelection.testStuckStoreCompaction:145->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 > expected:<[[]30, 30, 30]> but was:<[[99, 30, ]30, 30, 30]> -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (HBASE-19669) hbase1.3.1 (build hadoop2.7.4) shortcircuit problem
[
https://issues.apache.org/jira/browse/HBASE-19669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack reopened HBASE-19669:
---
> hbase1.3.1 (build hadoop2.7.4) shortcircuit problem
> ---
>
> Key: HBASE-19669
> URL: https://issues.apache.org/jira/browse/HBASE-19669
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 1.3.1
> Environment: Online HBase services, large requests
> hbase version: 1.3.1hadoop version: 2.7.4 os linux version: centos6.5
>Reporter: gehaijiang
>
> Online HBase services, large requests， hbase version: 1.3.1hadoop
> version: 2.7.4 os linux version: centos6.5
> hdfs-site.xml conf:
>
> dfs.client.read.shortcircuit
> true
> hdfs-site.xml
>
>
> dfs.domain.socket.path
> /var/run/hadoop-hdfs/dn_socket
> hdfs-site.xml
>
>
> os linux command :netstat -an
> unix 2 [ ACC ] STREAM LISTENING 10576083
> /var/run/hadoop-hdfs/dn_socket
> *{color:#d04437}problem :/var/run/hadoop-hdfs/dn_socket only one
> LISTENING， but no CONNECTED {color}*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (HBASE-19669) hbase1.3.1 (build hadoop2.7.4) shortcircuit problem
[
https://issues.apache.org/jira/browse/HBASE-19669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-19669.
---
Resolution: Fixed
Resolving. This is a question for the user list (I see you've asked the
question there already). Thanks.
> hbase1.3.1 (build hadoop2.7.4) shortcircuit problem
> ---
>
> Key: HBASE-19669
> URL: https://issues.apache.org/jira/browse/HBASE-19669
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 1.3.1
> Environment: Online HBase services, large requests
> hbase version: 1.3.1hadoop version: 2.7.4 os linux version: centos6.5
>Reporter: gehaijiang
>
> Online HBase services, large requests， hbase version: 1.3.1hadoop
> version: 2.7.4 os linux version: centos6.5
> hdfs-site.xml conf:
>
> dfs.client.read.shortcircuit
> true
> hdfs-site.xml
>
>
> dfs.domain.socket.path
> /var/run/hadoop-hdfs/dn_socket
> hdfs-site.xml
>
>
> os linux command :netstat -an
> unix 2 [ ACC ] STREAM LISTENING 10576083
> /var/run/hadoop-hdfs/dn_socket
> *{color:#d04437}problem :/var/run/hadoop-hdfs/dn_socket only one
> LISTENING， but no CONNECTED {color}*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (HBASE-19669) hbase1.3.1 (build hadoop2.7.4) shortcircuit problem
[
https://issues.apache.org/jira/browse/HBASE-19669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-19669.
---
Resolution: Invalid
> hbase1.3.1 (build hadoop2.7.4) shortcircuit problem
> ---
>
> Key: HBASE-19669
> URL: https://issues.apache.org/jira/browse/HBASE-19669
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 1.3.1
> Environment: Online HBase services, large requests
> hbase version: 1.3.1hadoop version: 2.7.4 os linux version: centos6.5
>Reporter: gehaijiang
>
> Online HBase services, large requests， hbase version: 1.3.1hadoop
> version: 2.7.4 os linux version: centos6.5
> hdfs-site.xml conf:
>
> dfs.client.read.shortcircuit
> true
> hdfs-site.xml
>
>
> dfs.domain.socket.path
> /var/run/hadoop-hdfs/dn_socket
> hdfs-site.xml
>
>
> os linux command :netstat -an
> unix 2 [ ACC ] STREAM LISTENING 10576083
> /var/run/hadoop-hdfs/dn_socket
> *{color:#d04437}problem :/var/run/hadoop-hdfs/dn_socket only one
> LISTENING， but no CONNECTED {color}*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19663) site build fails complaining "javadoc: error - class file for javax.annotation.meta.TypeQualifierNickname not found"
[
https://issues.apache.org/jira/browse/HBASE-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-19663:
--
Attachment: script.sh
My dumb script used doing git bisect trying to find breaking commit.
> site build fails complaining "javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found"
>
>
> Key: HBASE-19663
> URL: https://issues.apache.org/jira/browse/HBASE-19663
> Project: HBase
> Issue Type: Bug
> Components: site
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0-beta-1
>
> Attachments: script.sh
>
>
> Cryptic failure trying to build beta-1 RC. Fails like this:
> {code}
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 03:54 min
> [INFO] Finished at: 2017-12-29T01:13:15-08:00
> [INFO] Final Memory: 381M/9165M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
> hbase: Error generating maven-javadoc-plugin:2.10.3:aggregate:
> [ERROR] Exit code: 1 - warning: unknown enum constant When.ALWAYS
> [ERROR] reason: class file for javax.annotation.meta.When not found
> [ERROR] warning: unknown enum constant When.UNKNOWN
> [ERROR] warning: unknown enum constant When.MAYBE
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: malformed: "#matchingRows(Cell, byte[]))"
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR] javadoc: warning - Class javax.annotation.Nonnull not found.
> [ERROR] javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found
> [ERROR]
> [ERROR] Command line was: /home/stack/bin/jdk1.8.0_151/jre/../bin/javadoc
> -J-Xmx2G @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/stack/hbase.git/target/site/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}
> javax.annotation.meta.TypeQualifierNickname is out of jsr305 but we don't
> include this anywhere according to mvn dependency.
> Happens building the User API both test and main.
> Excluding these lines gets us passing again:
> {code}
> 3511
> 3512
> org.apache.yetus.audience.tools.IncludePublicAnnotationsStandardDoclet
> 3513
> 3514
> 3515 org.apache.yetus
> 3516 audience-annotations
> 3517 ${audience-annotations.version}
> 3518
> + 3519 true
> {code}
> Tried upgrading to newer mvn site (ours is three years old) but that a
> different set of problems.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19663) site build fails complaining "javadoc: error - class file for javax.annotation.meta.TypeQualifierNickname not found"
[
https://issues.apache.org/jira/browse/HBASE-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306396#comment-16306396
]
Mike Drob commented on HBASE-19663:
---
We pull this in via the findbugs annotation, I guess?
https://github.com/stephenc/findbugs-annotations/blob/findbugs-annotations-1.3.9-1/src/main/java/edu/umd/cs/findbugs/annotations/NonNull.java
This appears to still depend on the jsr305 jar?
> site build fails complaining "javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found"
>
>
> Key: HBASE-19663
> URL: https://issues.apache.org/jira/browse/HBASE-19663
> Project: HBase
> Issue Type: Bug
> Components: site
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0-beta-1
>
> Attachments: script.sh
>
>
> Cryptic failure trying to build beta-1 RC. Fails like this:
> {code}
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 03:54 min
> [INFO] Finished at: 2017-12-29T01:13:15-08:00
> [INFO] Final Memory: 381M/9165M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
> hbase: Error generating maven-javadoc-plugin:2.10.3:aggregate:
> [ERROR] Exit code: 1 - warning: unknown enum constant When.ALWAYS
> [ERROR] reason: class file for javax.annotation.meta.When not found
> [ERROR] warning: unknown enum constant When.UNKNOWN
> [ERROR] warning: unknown enum constant When.MAYBE
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: malformed: "#matchingRows(Cell, byte[]))"
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR] javadoc: warning - Class javax.annotation.Nonnull not found.
> [ERROR] javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found
> [ERROR]
> [ERROR] Command line was: /home/stack/bin/jdk1.8.0_151/jre/../bin/javadoc
> -J-Xmx2G @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/stack/hbase.git/target/site/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}
> javax.annotation.meta.TypeQualifierNickname is out of jsr305 but we don't
> include this anywhere according to mvn dependency.
> Happens building the User API both test and main.
> Excluding these lines gets us passing again:
> {code}
> 3511
> 3512
> org.apache.yetus.audience.tools.IncludePublicAnnotationsStandardDoclet
> 3513
> 3514
> 3515 org.apache.yetus
> 3516 audience-annotations
> 3517 ${audience-annotations.version}
> 3518
> + 3519 true
> {code}
> Tried upgrading to newer mvn site (ours is three years old) but that a
> different set of problems.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-8518) Get rid of hbase.hstore.compaction.complete setting
[
https://issues.apache.org/jira/browse/HBASE-8518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kuan-Po Tseng updated HBASE-8518:
-
Attachment: HBASE-8518.master.v4.patch
Modifying comments as below.
{code:java}
/**
* Create HStore instance.
* @return If Mob is enabled, return HMobStore, otherwise return
* HStoreForTesting, a HStore for testing.
*/
{code}
Thanks for your review.
> Get rid of hbase.hstore.compaction.complete setting
> ---
>
> Key: HBASE-8518
> URL: https://issues.apache.org/jira/browse/HBASE-8518
> Project: HBase
> Issue Type: Improvement
>Reporter: Sergey Shelukhin
>Assignee: Kuan-Po Tseng
>Priority: Minor
> Labels: beginner
> Attachments: HBASE-8518-1.patch, HBASE-8518.master.v0.patch,
> HBASE-8518.master.v1.patch, HBASE-8518.master.v2.patch,
> HBASE-8518.master.v3.patch, HBASE-8518.master.v4.patch, HBASE-8518.wip.patch
>
>
> hbase.hstore.compaction.complete is a strange setting that causes the
> finished compaction to not complete (files are just left in tmp) in HStore.
> It's used by one test.
> The setting with the same name is also used by CompactionTool, but that usage
> is semi-unrelated and could probably be removed easily.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19486) Periodically ensure records are not buffered too long by BufferedMutator
[ https://issues.apache.org/jira/browse/HBASE-19486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306411#comment-16306411 ] Hudson commented on HBASE-19486: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4307 (See [https://builds.apache.org/job/HBase-Trunk_matrix/4307/]) HBASE-19486 Periodically ensure records are not buffered too long by (chia7712: rev 5a1c36f70ac52e6f4e85f11ea0602d46b4861ac0) * (edit) hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestAsyncProcess.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/BufferedMutatorParams.java * (edit) hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestBufferedMutatorParams.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionImplementation.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/BufferedMutator.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionConfiguration.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/BufferedMutatorImpl.java > Periodically ensure records are not buffered too long by BufferedMutator > - > > Key: HBASE-19486 > URL: https://issues.apache.org/jira/browse/HBASE-19486 > Project: HBase > Issue Type: Improvement > Components: Client >Reporter: Niels Basjes >Assignee: Niels Basjes > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19486-20171212-2117.patch, > HBASE-19486-20171218-1229.patch, HBASE-19486-20171218-1300.patch, > HBASE-19486-20171219-0933.patch, HBASE-19486-20171219-1026.patch, > HBASE-19486-20171219-1122-trigger-qa-run.patch, > HBASE-19486-20171220-1612-trigger-qa-run.patch, > HBASE-19486-20171220-2228-trigger-qa-run.patch, > HBASE-19486-20171223-1438-trigger-qa-run.patch, > HBASE-19486-20171223-1728-trigger-qa-run.patch, > HBASE-19486-20171223--trigger-qa-run.patch, > HBASE-19486-20171224-1101-trigger-qa-run.patch, > HBASE-19486-20171224-1602.patch, HBASE-19486-branch-1.v0.patch, > HBASE-19486-branch-1.v1.patch, HBASE-19486.v0.patch > > > I'm working on several projects where we are doing stream / event type > processing instead of batch type processing. We mostly use Apache Flink and > Apache Beam for these projects. > When we ingest a continuous stream of events and feed that into HBase via a > BufferedMutator this all works fine. The buffer fills up at a predictable > rate and we can make sure it flushes several times per second into HBase by > tuning the buffer size. > We also have situations where the event rate is unpredictable. Some times > because the source is in reality a batch job that puts records into Kafka, > sometimes because it is the "predictable in production" application in our > testing environment (where only the dev triggers a handful of events). > For these kinds of use cases we need a way to 'force' the BufferedMutator to > automatically flush any records in the buffer even if the buffer is not full. > I'll put up a pull request with a proposed implementation for review against > the master (i.e. 3.0.0). > When approved I would like to backport this to the 1.x and 2.x versions of > the client in the same (as close as possible) way. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19666) hadoop.hbase.regionserver.TestDefaultCompactSelection test failed
[ https://issues.apache.org/jira/browse/HBASE-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19666: --- Attachment: HBASE-19666.v0.patch Looped the TestDefaultCompactSelection 20 times. All pass. > hadoop.hbase.regionserver.TestDefaultCompactSelection test failed > - > > Key: HBASE-19666 > URL: https://issues.apache.org/jira/browse/HBASE-19666 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0 >Reporter: Jingyun Tian >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19666.v0.patch > > > hadoop.hbase.regionserver.TestDefaultCompactSelection > [ERROR] Failures: > [ERROR] > TestDefaultCompactSelection.testCompactionRatio:74->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 > expected:<[[4, 2, 1]]> but was:<[[]]> > [ERROR] > TestDefaultCompactSelection.testStuckStoreCompaction:145->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 > expected:<[[]30, 30, 30]> but was:<[[99, 30, ]30, 30, 30]> -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19666) hadoop.hbase.regionserver.TestDefaultCompactSelection test failed
[ https://issues.apache.org/jira/browse/HBASE-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19666: --- Status: Patch Available (was: Open) > hadoop.hbase.regionserver.TestDefaultCompactSelection test failed > - > > Key: HBASE-19666 > URL: https://issues.apache.org/jira/browse/HBASE-19666 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0 >Reporter: Jingyun Tian >Assignee: Chia-Ping Tsai >Priority: Critical > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19666.v0.patch > > > hadoop.hbase.regionserver.TestDefaultCompactSelection > [ERROR] Failures: > [ERROR] > TestDefaultCompactSelection.testCompactionRatio:74->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 > expected:<[[4, 2, 1]]> but was:<[[]]> > [ERROR] > TestDefaultCompactSelection.testStuckStoreCompaction:145->TestCompactionPolicy.compactEquals:182->TestCompactionPolicy.compactEquals:201 > expected:<[[]30, 30, 30]> but was:<[[99, 30, ]30, 30, 30]> -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19667) Get rid of MasterEnvironment#supportGroupCPs
[
https://issues.apache.org/jira/browse/HBASE-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19667:
---
Attachment: HBASE-19667.v0.patch
> Get rid of MasterEnvironment#supportGroupCPs
>
>
> Key: HBASE-19667
> URL: https://issues.apache.org/jira/browse/HBASE-19667
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19667.v0.patch
>
>
> copy the discussion from HBASE-19500.
> {quote}
> Appy:
> Can we remove {{if(((MasterEnvironment)getEnvironment()).supportGroupCPs) }}
> in so many places since CP in 2.0 are already broken left and right (and
> we'll have to solve legacy issue more holistically) What say Anoop Sam John?
> Chia:
> The cp user must do something to migrate their cp code from 1.x to 2.0
> anyway, hence the check is unnecessary in 2.0 I'd say. Seems it is unrelated
> to this jira. Iron out it in another jira?
> Appy:
> Chia-Ping Tsai you can take up the check removal?
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19667) Get rid of MasterEnvironment#supportGroupCPs
[
https://issues.apache.org/jira/browse/HBASE-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19667:
---
Status: Patch Available (was: Open)
> Get rid of MasterEnvironment#supportGroupCPs
>
>
> Key: HBASE-19667
> URL: https://issues.apache.org/jira/browse/HBASE-19667
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19667.v0.patch
>
>
> copy the discussion from HBASE-19500.
> {quote}
> Appy:
> Can we remove {{if(((MasterEnvironment)getEnvironment()).supportGroupCPs) }}
> in so many places since CP in 2.0 are already broken left and right (and
> we'll have to solve legacy issue more holistically) What say Anoop Sam John?
> Chia:
> The cp user must do something to migrate their cp code from 1.x to 2.0
> anyway, hence the check is unnecessary in 2.0 I'd say. Seems it is unrelated
> to this jira. Iron out it in another jira?
> Appy:
> Chia-Ping Tsai you can take up the check removal?
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-8518) Get rid of hbase.hstore.compaction.complete setting
[ https://issues.apache.org/jira/browse/HBASE-8518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-8518: -- Fix Version/s: 2.0.0-beta-2 > Get rid of hbase.hstore.compaction.complete setting > --- > > Key: HBASE-8518 > URL: https://issues.apache.org/jira/browse/HBASE-8518 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Kuan-Po Tseng >Priority: Minor > Labels: beginner > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-8518-1.patch, HBASE-8518.master.v0.patch, > HBASE-8518.master.v1.patch, HBASE-8518.master.v2.patch, > HBASE-8518.master.v3.patch, HBASE-8518.master.v4.patch, HBASE-8518.wip.patch > > > hbase.hstore.compaction.complete is a strange setting that causes the > finished compaction to not complete (files are just left in tmp) in HStore. > It's used by one test. > The setting with the same name is also used by CompactionTool, but that usage > is semi-unrelated and could probably be removed easily. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-8518) Get rid of hbase.hstore.compaction.complete setting
[ https://issues.apache.org/jira/browse/HBASE-8518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-8518: -- Status: Patch Available (was: Open) > Get rid of hbase.hstore.compaction.complete setting > --- > > Key: HBASE-8518 > URL: https://issues.apache.org/jira/browse/HBASE-8518 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Kuan-Po Tseng >Priority: Minor > Labels: beginner > Attachments: HBASE-8518-1.patch, HBASE-8518.master.v0.patch, > HBASE-8518.master.v1.patch, HBASE-8518.master.v2.patch, > HBASE-8518.master.v3.patch, HBASE-8518.master.v4.patch, HBASE-8518.wip.patch > > > hbase.hstore.compaction.complete is a strange setting that causes the > finished compaction to not complete (files are just left in tmp) in HStore. > It's used by one test. > The setting with the same name is also used by CompactionTool, but that usage > is semi-unrelated and could probably be removed easily. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19663) site build fails complaining "javadoc: error - class file for javax.annotation.meta.TypeQualifierNickname not found"
[
https://issues.apache.org/jira/browse/HBASE-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306419#comment-16306419
]
stack commented on HBASE-19663:
---
There is Nonnull and NonNull is that right? Where is it used? Grepping I didn't
see where we were making use of it. [~mdrob]
> site build fails complaining "javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found"
>
>
> Key: HBASE-19663
> URL: https://issues.apache.org/jira/browse/HBASE-19663
> Project: HBase
> Issue Type: Bug
> Components: site
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0-beta-1
>
> Attachments: script.sh
>
>
> Cryptic failure trying to build beta-1 RC. Fails like this:
> {code}
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 03:54 min
> [INFO] Finished at: 2017-12-29T01:13:15-08:00
> [INFO] Final Memory: 381M/9165M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
> hbase: Error generating maven-javadoc-plugin:2.10.3:aggregate:
> [ERROR] Exit code: 1 - warning: unknown enum constant When.ALWAYS
> [ERROR] reason: class file for javax.annotation.meta.When not found
> [ERROR] warning: unknown enum constant When.UNKNOWN
> [ERROR] warning: unknown enum constant When.MAYBE
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: malformed: "#matchingRows(Cell, byte[]))"
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR] javadoc: warning - Class javax.annotation.Nonnull not found.
> [ERROR] javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found
> [ERROR]
> [ERROR] Command line was: /home/stack/bin/jdk1.8.0_151/jre/../bin/javadoc
> -J-Xmx2G @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/stack/hbase.git/target/site/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}
> javax.annotation.meta.TypeQualifierNickname is out of jsr305 but we don't
> include this anywhere according to mvn dependency.
> Happens building the User API both test and main.
> Excluding these lines gets us passing again:
> {code}
> 3511
> 3512
> org.apache.yetus.audience.tools.IncludePublicAnnotationsStandardDoclet
> 3513
> 3514
> 3515 org.apache.yetus
> 3516 audience-annotations
> 3517 ${audience-annotations.version}
> 3518
> + 3519 true
> {code}
> Tried upgrading to newer mvn site (ours is three years old) but that a
> different set of problems.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-8518) Get rid of hbase.hstore.compaction.complete setting
[
https://issues.apache.org/jira/browse/HBASE-8518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306425#comment-16306425
]
Chia-Ping Tsai commented on HBASE-8518:
---
Replace the "hbase.hregion.impl" by HConstants.REGION_IMPL
{code}
public void testRecoveredEditsReplayCompaction(boolean mismatchedRegionName)
throws Exception {
+CONF.setClass("hbase.hregion.impl", HRegionForTesting.class, Region.class);
{code}
The IA.Private is unnecessary in this test file.
{code}
+ @InterfaceAudience.Private
+ public static class HStoreForTesting extends HStore {
{code}
{code}
+ @InterfaceAudience.Private
+ public static class HRegionForTesting extends HRegion {
{code}
> Get rid of hbase.hstore.compaction.complete setting
> ---
>
> Key: HBASE-8518
> URL: https://issues.apache.org/jira/browse/HBASE-8518
> Project: HBase
> Issue Type: Improvement
>Reporter: Sergey Shelukhin
>Assignee: Kuan-Po Tseng
>Priority: Minor
> Labels: beginner
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-8518-1.patch, HBASE-8518.master.v0.patch,
> HBASE-8518.master.v1.patch, HBASE-8518.master.v2.patch,
> HBASE-8518.master.v3.patch, HBASE-8518.master.v4.patch, HBASE-8518.wip.patch
>
>
> hbase.hstore.compaction.complete is a strange setting that causes the
> finished compaction to not complete (files are just left in tmp) in HStore.
> It's used by one test.
> The setting with the same name is also used by CompactionTool, but that usage
> is semi-unrelated and could probably be removed easily.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (HBASE-19670) Workaround: Purge User API building from branch-2 so can make a beta-1
[ https://issues.apache.org/jira/browse/HBASE-19670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-19670. --- Resolution: Fixed Assignee: stack Release Note: Disable filtering of User API based off yetus annotation done in doclet. See parent issue for build failure currently being worked on but not done in time for a beta-1. Pushed on branch-2. > Workaround: Purge User API building from branch-2 so can make a beta-1 > -- > > Key: HBASE-19670 > URL: https://issues.apache.org/jira/browse/HBASE-19670 > Project: HBase > Issue Type: Sub-task > Components: site >Reporter: stack >Assignee: stack > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19670.branch-2.001.patch > > > Entertaining idea of purging User API doc generation from branch-2 because am > unable to figure why it broke (see parent issue). I don't want to hold up > beta-1 for this. Filing placeholder issue against which I can hang testing > this alternative. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-8518) Get rid of hbase.hstore.compaction.complete setting
[ https://issues.apache.org/jira/browse/HBASE-8518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kuan-Po Tseng updated HBASE-8518: - Attachment: HBASE-8518.master.v5.patch Fixed that. Thanks for your advice. > Get rid of hbase.hstore.compaction.complete setting > --- > > Key: HBASE-8518 > URL: https://issues.apache.org/jira/browse/HBASE-8518 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Kuan-Po Tseng >Priority: Minor > Labels: beginner > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-8518-1.patch, HBASE-8518.master.v0.patch, > HBASE-8518.master.v1.patch, HBASE-8518.master.v2.patch, > HBASE-8518.master.v3.patch, HBASE-8518.master.v4.patch, > HBASE-8518.master.v5.patch, HBASE-8518.wip.patch > > > hbase.hstore.compaction.complete is a strange setting that causes the > finished compaction to not complete (files are just left in tmp) in HStore. > It's used by one test. > The setting with the same name is also used by CompactionTool, but that usage > is semi-unrelated and could probably be removed easily. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19663) site build fails complaining "javadoc: error - class file for javax.annotation.meta.TypeQualifierNickname not found"
[
https://issues.apache.org/jira/browse/HBASE-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306435#comment-16306435
]
stack commented on HBASE-19663:
---
Pushed this out to beta-2.
> site build fails complaining "javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found"
>
>
> Key: HBASE-19663
> URL: https://issues.apache.org/jira/browse/HBASE-19663
> Project: HBase
> Issue Type: Bug
> Components: site
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0-beta-2
>
> Attachments: script.sh
>
>
> Cryptic failure trying to build beta-1 RC. Fails like this:
> {code}
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 03:54 min
> [INFO] Finished at: 2017-12-29T01:13:15-08:00
> [INFO] Final Memory: 381M/9165M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
> hbase: Error generating maven-javadoc-plugin:2.10.3:aggregate:
> [ERROR] Exit code: 1 - warning: unknown enum constant When.ALWAYS
> [ERROR] reason: class file for javax.annotation.meta.When not found
> [ERROR] warning: unknown enum constant When.UNKNOWN
> [ERROR] warning: unknown enum constant When.MAYBE
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: malformed: "#matchingRows(Cell, byte[]))"
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR] javadoc: warning - Class javax.annotation.Nonnull not found.
> [ERROR] javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found
> [ERROR]
> [ERROR] Command line was: /home/stack/bin/jdk1.8.0_151/jre/../bin/javadoc
> -J-Xmx2G @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/stack/hbase.git/target/site/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}
> javax.annotation.meta.TypeQualifierNickname is out of jsr305 but we don't
> include this anywhere according to mvn dependency.
> Happens building the User API both test and main.
> Excluding these lines gets us passing again:
> {code}
> 3511
> 3512
> org.apache.yetus.audience.tools.IncludePublicAnnotationsStandardDoclet
> 3513
> 3514
> 3515 org.apache.yetus
> 3516 audience-annotations
> 3517 ${audience-annotations.version}
> 3518
> + 3519 true
> {code}
> Tried upgrading to newer mvn site (ours is three years old) but that a
> different set of problems.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19196) Release hbase-2.0.0-beta-1; the "Finish-line" release
[ https://issues.apache.org/jira/browse/HBASE-19196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306436#comment-16306436 ] stack commented on HBASE-19196: --- Pushed first RC with 'known issue' HBASE-19663 and HBASE-19670 workaround. > Release hbase-2.0.0-beta-1; the "Finish-line" release > - > > Key: HBASE-19196 > URL: https://issues.apache.org/jira/browse/HBASE-19196 > Project: HBase > Issue Type: Bug >Reporter: stack >Priority: Blocker > Fix For: 2.0.0-beta-1 > > > APIs done, but external facing and Coprocessors. Done w/ features. Bug fixes > only from here on out. There'll be a beta-2 but that is about rolling upgrade > and bug fixes only. Then our first 2.0.0 Release Candidate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19663) site build fails complaining "javadoc: error - class file for javax.annotation.meta.TypeQualifierNickname not found"
[
https://issues.apache.org/jira/browse/HBASE-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-19663:
--
Fix Version/s: (was: 2.0.0-beta-1)
2.0.0-beta-2
> site build fails complaining "javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found"
>
>
> Key: HBASE-19663
> URL: https://issues.apache.org/jira/browse/HBASE-19663
> Project: HBase
> Issue Type: Bug
> Components: site
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0-beta-2
>
> Attachments: script.sh
>
>
> Cryptic failure trying to build beta-1 RC. Fails like this:
> {code}
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 03:54 min
> [INFO] Finished at: 2017-12-29T01:13:15-08:00
> [INFO] Final Memory: 381M/9165M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
> hbase: Error generating maven-javadoc-plugin:2.10.3:aggregate:
> [ERROR] Exit code: 1 - warning: unknown enum constant When.ALWAYS
> [ERROR] reason: class file for javax.annotation.meta.When not found
> [ERROR] warning: unknown enum constant When.UNKNOWN
> [ERROR] warning: unknown enum constant When.MAYBE
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: malformed: "#matchingRows(Cell, byte[]))"
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR] javadoc: warning - Class javax.annotation.Nonnull not found.
> [ERROR] javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found
> [ERROR]
> [ERROR] Command line was: /home/stack/bin/jdk1.8.0_151/jre/../bin/javadoc
> -J-Xmx2G @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/stack/hbase.git/target/site/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}
> javax.annotation.meta.TypeQualifierNickname is out of jsr305 but we don't
> include this anywhere according to mvn dependency.
> Happens building the User API both test and main.
> Excluding these lines gets us passing again:
> {code}
> 3511
> 3512
> org.apache.yetus.audience.tools.IncludePublicAnnotationsStandardDoclet
> 3513
> 3514
> 3515 org.apache.yetus
> 3516 audience-annotations
> 3517 ${audience-annotations.version}
> 3518
> + 3519 true
> {code}
> Tried upgrading to newer mvn site (ours is three years old) but that a
> different set of problems.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19663) site build fails complaining "javadoc: error - class file for javax.annotation.meta.TypeQualifierNickname not found"
[
https://issues.apache.org/jira/browse/HBASE-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306444#comment-16306444
]
stack commented on HBASE-19663:
---
To be clear, subtask undoes doclet filtering building User API for the moment
so can push beta-1. This is blocker on beta-2. Means turning on the User API
filter again.
> site build fails complaining "javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found"
>
>
> Key: HBASE-19663
> URL: https://issues.apache.org/jira/browse/HBASE-19663
> Project: HBase
> Issue Type: Bug
> Components: site
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0-beta-2
>
> Attachments: script.sh
>
>
> Cryptic failure trying to build beta-1 RC. Fails like this:
> {code}
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 03:54 min
> [INFO] Finished at: 2017-12-29T01:13:15-08:00
> [INFO] Final Memory: 381M/9165M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
> hbase: Error generating maven-javadoc-plugin:2.10.3:aggregate:
> [ERROR] Exit code: 1 - warning: unknown enum constant When.ALWAYS
> [ERROR] reason: class file for javax.annotation.meta.When not found
> [ERROR] warning: unknown enum constant When.UNKNOWN
> [ERROR] warning: unknown enum constant When.MAYBE
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: malformed: "#matchingRows(Cell, byte[]))"
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR] javadoc: warning - Class javax.annotation.Nonnull not found.
> [ERROR] javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found
> [ERROR]
> [ERROR] Command line was: /home/stack/bin/jdk1.8.0_151/jre/../bin/javadoc
> -J-Xmx2G @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/stack/hbase.git/target/site/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}
> javax.annotation.meta.TypeQualifierNickname is out of jsr305 but we don't
> include this anywhere according to mvn dependency.
> Happens building the User API both test and main.
> Excluding these lines gets us passing again:
> {code}
> 3511
> 3512
> org.apache.yetus.audience.tools.IncludePublicAnnotationsStandardDoclet
> 3513
> 3514
> 3515 org.apache.yetus
> 3516 audience-annotations
> 3517 ${audience-annotations.version}
> 3518
> + 3519 true
> {code}
> Tried upgrading to newer mvn site (ours is three years old) but that a
> different set of problems.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19662) hbase-metrics-api fails checkstyle due to wrong import order
[
https://issues.apache.org/jira/browse/HBASE-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306472#comment-16306472
]
Chia-Ping Tsai commented on HBASE-19662:
bq. Oh, interesting, I get this error locally when running mvn site! That's
some kind of progress.
I run the {{mvn clean site}} but no failure happen.
> hbase-metrics-api fails checkstyle due to wrong import order
>
>
> Key: HBASE-19662
> URL: https://issues.apache.org/jira/browse/HBASE-19662
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Minor
> Attachments: 19662.v1.txt
>
>
> In recent trunk builds, there were the following errors:
> {code}
> [ERROR]
> src/main/java/org/apache/hadoop/hbase/metrics/MetricRegistriesLoader.java:[31]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.annotations.VisibleForTesting'
> import.
> [ERROR]
> src/test/java/org/apache/hadoop/hbase/metrics/TestMetricRegistriesLoader.java:[28]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.collect.Lists' import.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-8518) Get rid of hbase.hstore.compaction.complete setting
[
https://issues.apache.org/jira/browse/HBASE-8518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306485#comment-16306485
]
Hadoop QA commented on HBASE-8518:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
12s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
7s{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
45s{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
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
5s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
7s{color} | {color:red} hbase-server: The patch generated 1 new + 109 unchanged
- 0 fixed = 110 total (was 109) {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
50s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 3s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
44s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 26m 19s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 14m
14s{color} | {color:green} hbase-mapreduce in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 82m 42s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestMemstoreLABWithoutPool |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-8518 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12904034/HBASE-8518.master.v5.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 6960959a20b8 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 5a1c36f70a |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d
[jira] [Commented] (HBASE-19662) hbase-metrics-api fails checkstyle due to wrong import order
[
https://issues.apache.org/jira/browse/HBASE-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306490#comment-16306490
]
Chia-Ping Tsai commented on HBASE-19662:
I run the command - {{mvn clean -DskipTests package findbugs:findbugs}} and
{{mvn -DskipTests package checkstyle:checkstyle}} - used by jenkis. still
pass..
> hbase-metrics-api fails checkstyle due to wrong import order
>
>
> Key: HBASE-19662
> URL: https://issues.apache.org/jira/browse/HBASE-19662
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Minor
> Attachments: 19662.v1.txt
>
>
> In recent trunk builds, there were the following errors:
> {code}
> [ERROR]
> src/main/java/org/apache/hadoop/hbase/metrics/MetricRegistriesLoader.java:[31]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.annotations.VisibleForTesting'
> import.
> [ERROR]
> src/test/java/org/apache/hadoop/hbase/metrics/TestMetricRegistriesLoader.java:[28]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.collect.Lists' import.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19663) site build fails complaining "javadoc: error - class file for javax.annotation.meta.TypeQualifierNickname not found"
[
https://issues.apache.org/jira/browse/HBASE-19663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306495#comment-16306495
]
Mike Drob commented on HBASE-19663:
---
lots of older commits failing with {{error - class file for
javax.annotation.concurrent.Immutable not found}}
> site build fails complaining "javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found"
>
>
> Key: HBASE-19663
> URL: https://issues.apache.org/jira/browse/HBASE-19663
> Project: HBase
> Issue Type: Bug
> Components: site
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0-beta-2
>
> Attachments: script.sh
>
>
> Cryptic failure trying to build beta-1 RC. Fails like this:
> {code}
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 03:54 min
> [INFO] Finished at: 2017-12-29T01:13:15-08:00
> [INFO] Final Memory: 381M/9165M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
> hbase: Error generating maven-javadoc-plugin:2.10.3:aggregate:
> [ERROR] Exit code: 1 - warning: unknown enum constant When.ALWAYS
> [ERROR] reason: class file for javax.annotation.meta.When not found
> [ERROR] warning: unknown enum constant When.UNKNOWN
> [ERROR] warning: unknown enum constant When.MAYBE
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: malformed: "#matchingRows(Cell, byte[]))"
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR]
> /home/stack/hbase.git/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java:762:
> warning - Tag @link: reference not found: #matchingRows(Cell, byte[]))
> [ERROR] javadoc: warning - Class javax.annotation.Nonnull not found.
> [ERROR] javadoc: error - class file for
> javax.annotation.meta.TypeQualifierNickname not found
> [ERROR]
> [ERROR] Command line was: /home/stack/bin/jdk1.8.0_151/jre/../bin/javadoc
> -J-Xmx2G @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/home/stack/hbase.git/target/site/apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {code}
> javax.annotation.meta.TypeQualifierNickname is out of jsr305 but we don't
> include this anywhere according to mvn dependency.
> Happens building the User API both test and main.
> Excluding these lines gets us passing again:
> {code}
> 3511
> 3512
> org.apache.yetus.audience.tools.IncludePublicAnnotationsStandardDoclet
> 3513
> 3514
> 3515 org.apache.yetus
> 3516 audience-annotations
> 3517 ${audience-annotations.version}
> 3518
> + 3519 true
> {code}
> Tried upgrading to newer mvn site (ours is three years old) but that a
> different set of problems.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19662) hbase-metrics-api fails checkstyle due to wrong import order
[
https://issues.apache.org/jira/browse/HBASE-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306506#comment-16306506
]
Chia-Ping Tsai commented on HBASE-19662:
bq. can somebody manually deploy the latest snapshot and see if that fixes
things?
I get the error if I remove hbase from local repository. Seems maven use the
checkstyle rule from the snapshot file.
{code}
[DEBUG] The resource 'hbase/checkstyle.xml' was not found with resourceLoader
org.codehaus.plexus.resource.loader.URLResourceLoader.
[DEBUG] The resource 'hbase/checkstyle.xml' was not found with resourceLoader
org.codehaus.plexus.resource.loader.JarResourceLoader.
[DEBUG] The resource 'hbase/checkstyle.xml' was not found with resourceLoader
org.codehaus.plexus.resource.loader.FileResourceLoader.
[DEBUG] The resource 'hbase/checkstyle.xml' was found as
jar:file:/home/chia7712/.m2/repository/org/apache/hbase/hbase-checkstyle/3.0.0-SNAPSHOT/hbase-checkstyle-3.0.0-SNAPSHOT.jar!/hbase/checkstyle.xml.
{code}
And the rule is decrepit.
{code}
{code}
> hbase-metrics-api fails checkstyle due to wrong import order
>
>
> Key: HBASE-19662
> URL: https://issues.apache.org/jira/browse/HBASE-19662
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Minor
> Attachments: 19662.v1.txt
>
>
> In recent trunk builds, there were the following errors:
> {code}
> [ERROR]
> src/main/java/org/apache/hadoop/hbase/metrics/MetricRegistriesLoader.java:[31]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.annotations.VisibleForTesting'
> import.
> [ERROR]
> src/test/java/org/apache/hadoop/hbase/metrics/TestMetricRegistriesLoader.java:[28]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.collect.Lists' import.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-8518) Get rid of hbase.hstore.compaction.complete setting
[ https://issues.apache.org/jira/browse/HBASE-8518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306507#comment-16306507 ] Chia-Ping Tsai commented on HBASE-8518: --- TestMemstoreLABWithoutPool pass locally, and it should be unrelated to the patch. Will commit it with checkstyle fixes. > Get rid of hbase.hstore.compaction.complete setting > --- > > Key: HBASE-8518 > URL: https://issues.apache.org/jira/browse/HBASE-8518 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Kuan-Po Tseng >Priority: Minor > Labels: beginner > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-8518-1.patch, HBASE-8518.master.v0.patch, > HBASE-8518.master.v1.patch, HBASE-8518.master.v2.patch, > HBASE-8518.master.v3.patch, HBASE-8518.master.v4.patch, > HBASE-8518.master.v5.patch, HBASE-8518.wip.patch > > > hbase.hstore.compaction.complete is a strange setting that causes the > finished compaction to not complete (files are just left in tmp) in HStore. > It's used by one test. > The setting with the same name is also used by CompactionTool, but that usage > is semi-unrelated and could probably be removed easily. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19662) hbase-metrics-api fails checkstyle due to wrong import order
[
https://issues.apache.org/jira/browse/HBASE-19662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306510#comment-16306510
]
Chia-Ping Tsai commented on HBASE-19662:
[~mdrob] Should jenkins run the {{install}} first? Otherwise the similar error
may happen in the future.
> hbase-metrics-api fails checkstyle due to wrong import order
>
>
> Key: HBASE-19662
> URL: https://issues.apache.org/jira/browse/HBASE-19662
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Minor
> Attachments: 19662.v1.txt
>
>
> In recent trunk builds, there were the following errors:
> {code}
> [ERROR]
> src/main/java/org/apache/hadoop/hbase/metrics/MetricRegistriesLoader.java:[31]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.annotations.VisibleForTesting'
> import.
> [ERROR]
> src/test/java/org/apache/hadoop/hbase/metrics/TestMetricRegistriesLoader.java:[28]
> (imports) ImportOrder: Wrong order for
> 'org.apache.hbase.thirdparty.com.google.common.collect.Lists' import.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-8518) Get rid of hbase.hstore.compaction.complete setting
[
https://issues.apache.org/jira/browse/HBASE-8518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306515#comment-16306515
]
Hadoop QA commented on HBASE-8518:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
51s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
11s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
55s{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
40s{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
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
8s{color} | {color:red} hbase-server: The patch generated 1 new + 109 unchanged
- 0 fixed = 110 total (was 109) {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}
20m 6s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 99m 54s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 10m
46s{color} | {color:green} hbase-mapreduce in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
37s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}153m 49s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-8518 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12904028/HBASE-8518.master.v4.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 1f27e47cc607 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 5a1c36f70a |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| checkstyle |
https://builds.apache.org/job/PreComm
[jira] [Commented] (HBASE-19667) Get rid of MasterEnvironment#supportGroupCPs
[
https://issues.apache.org/jira/browse/HBASE-19667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306517#comment-16306517
]
Hadoop QA commented on HBASE-19667:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
59s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
58s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
47s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
5s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
47s{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
32s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
44s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 41s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}113m
12s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
18s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}155m 46s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19667 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12904031/HBASE-19667.v0.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux e77b1abd65db 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19
15:49:21 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 5a1c36f70a |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/10791/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10791/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> Get rid of MasterEnvironment#supportGroupCPs
> -
[jira] [Commented] (HBASE-19666) hadoop.hbase.regionserver.TestDefaultCompactSelection test failed
[
https://issues.apache.org/jira/browse/HBASE-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306518#comment-16306518
]
Hadoop QA commented on HBASE-19666:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 1m
57s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
2s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
47s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
5s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
49s{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
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
40s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 32s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}113m
47s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}156m 14s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19666 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12904030/HBASE-19666.v0.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux b78b7a510bd7 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19
15:49:21 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 5a1c36f70a |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/10792/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/10792/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> hadoop.hbase.regionserver.TestDefaultCompactSelection test failed
> -
>
> Key: HBASE-19666
> URL: https://issues.apa
[jira] [Updated] (HBASE-8518) Get rid of hbase.hstore.compaction.complete setting
[ https://issues.apache.org/jira/browse/HBASE-8518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-8518: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Thanks for the patch. [~brandboat] > Get rid of hbase.hstore.compaction.complete setting > --- > > Key: HBASE-8518 > URL: https://issues.apache.org/jira/browse/HBASE-8518 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Kuan-Po Tseng >Priority: Minor > Labels: beginner > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-8518-1.patch, HBASE-8518.master.v0.patch, > HBASE-8518.master.v1.patch, HBASE-8518.master.v2.patch, > HBASE-8518.master.v3.patch, HBASE-8518.master.v4.patch, > HBASE-8518.master.v5.patch, HBASE-8518.wip.patch > > > hbase.hstore.compaction.complete is a strange setting that causes the > finished compaction to not complete (files are just left in tmp) in HStore. > It's used by one test. > The setting with the same name is also used by CompactionTool, but that usage > is semi-unrelated and could probably be removed easily. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19651) Remove LimitInputStream
[
https://issues.apache.org/jira/browse/HBASE-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306535#comment-16306535
]
BELUGA BEHR commented on HBASE-19651:
-
@stack [~mdrob]
I tested it out on my system, for two test I made up:
{{Bytes.limit}} - 578ms & 180ms
{{BoundedInputStream}} - 663ms & 257ms
So ya, {{Bytes.limit}} is faster... maybe need to let the Commons folks know
and comment on the difference.
> Remove LimitInputStream
> ---
>
> Key: HBASE-19651
> URL: https://issues.apache.org/jira/browse/HBASE-19651
> Project: HBase
> Issue Type: Improvement
> Components: hbase
>Affects Versions: 3.0.0, 2.0.0-beta-2
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Minor
> Attachments: HBASE-19651.1.patch, HBASE-19651.2.patch
>
>
> Let us "drink our own champagne" and use the existing Apache Commons
> BoundedInputStream instead.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19651) Remove LimitInputStream
[ https://issues.apache.org/jira/browse/HBASE-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HBASE-19651: Attachment: (was: HBASE-x19651.3.patch) > Remove LimitInputStream > --- > > Key: HBASE-19651 > URL: https://issues.apache.org/jira/browse/HBASE-19651 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0, 2.0.0-beta-2 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Minor > Attachments: HBASE-19651.1.patch, HBASE-19651.2.patch, > HBASE-19651.3.patch > > > Let us "drink our own champagne" and use the existing Apache Commons > BoundedInputStream instead. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19651) Remove LimitInputStream
[ https://issues.apache.org/jira/browse/HBASE-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HBASE-19651: Attachment: HBASE-x19651.3.patch > Remove LimitInputStream > --- > > Key: HBASE-19651 > URL: https://issues.apache.org/jira/browse/HBASE-19651 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0, 2.0.0-beta-2 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Minor > Attachments: HBASE-19651.1.patch, HBASE-19651.2.patch, > HBASE-19651.3.patch > > > Let us "drink our own champagne" and use the existing Apache Commons > BoundedInputStream instead. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19651) Remove LimitInputStream
[ https://issues.apache.org/jira/browse/HBASE-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HBASE-19651: Attachment: HBASE-19651.3.patch > Remove LimitInputStream > --- > > Key: HBASE-19651 > URL: https://issues.apache.org/jira/browse/HBASE-19651 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0, 2.0.0-beta-2 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Minor > Attachments: HBASE-19651.1.patch, HBASE-19651.2.patch, > HBASE-19651.3.patch > > > Let us "drink our own champagne" and use the existing Apache Commons > BoundedInputStream instead. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19651) Remove LimitInputStream
[ https://issues.apache.org/jira/browse/HBASE-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HBASE-19651: Status: Patch Available (was: Reopened) OK... then how about we remove this local copy and just use the copy directly from Guava? > Remove LimitInputStream > --- > > Key: HBASE-19651 > URL: https://issues.apache.org/jira/browse/HBASE-19651 > Project: HBase > Issue Type: Improvement > Components: hbase >Affects Versions: 3.0.0, 2.0.0-beta-2 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Minor > Attachments: HBASE-19651.1.patch, HBASE-19651.2.patch, > HBASE-19651.3.patch > > > Let us "drink our own champagne" and use the existing Apache Commons > BoundedInputStream instead. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19651) Remove LimitInputStream
[
https://issues.apache.org/jira/browse/HBASE-19651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306548#comment-16306548
]
Mike Drob commented on HBASE-19651:
---
If we're going to use classes from guava, then we should be using the ones
located at {{org.apache.hbase.thirdparty.com.google}} - otherwise they are
likely to break when the transitively pulled in version of guava changes.
> Remove LimitInputStream
> ---
>
> Key: HBASE-19651
> URL: https://issues.apache.org/jira/browse/HBASE-19651
> Project: HBase
> Issue Type: Improvement
> Components: hbase
>Affects Versions: 3.0.0, 2.0.0-beta-2
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Minor
> Attachments: HBASE-19651.1.patch, HBASE-19651.2.patch,
> HBASE-19651.3.patch
>
>
> Let us "drink our own champagne" and use the existing Apache Commons
> BoundedInputStream instead.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
