[jira] [Updated] (HBASE-22169) Coprocessor path wrong then Region open failed cause memory leak
[
https://issues.apache.org/jira/browse/HBASE-22169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bing Xiao updated HBASE-22169:
--
Attachment: HBASE-22169-master-v1.patch
HBASE-22169-branch-2.1-v1.patch
HBASE-22169-branch-2-v1.patch
> Coprocessor path wrong then Region open failed cause memory leak
>
>
> Key: HBASE-22169
> URL: https://issues.apache.org/jira/browse/HBASE-22169
> Project: HBase
> Issue Type: Bug
>Reporter: Bing Xiao
>Assignee: Bing Xiao
>Priority: Major
> Attachments: HBASE-22169-branch-2-v1.patch,
> HBASE-22169-branch-2.1-v1.patch, HBASE-22169-master-v1.patch
>
>
> By coprocessor path wrong region will open failed, MetricsRegionWrapperImpl
> is already init and not close, cause memory leak;
> {code:java}
> 2019-02-21 15:41:32,929 ERROR
> [RS_OPEN_REGION-hb-2zedsc3fxjn12dl6u-005:16020-7]
> regionserver.RegionCoprocessorHost(362): Failed to load coprocessor
> org.apache.kylin.storage.hbase.cube.v2.coprocessor.endpoint.CubeVisitService
> java.lang.IllegalArgumentException: java.net.UnknownHostException: emr-cluster
> at
> org.apache.hadoop.security.SecurityUtil.buildTokenService(SecurityUtil.java:378)
> at
> org.apache.hadoop.hdfs.NameNodeProxies.createNonHAProxy(NameNodeProxies.java:310)
> at
> org.apache.hadoop.hdfs.NameNodeProxies.createProxy(NameNodeProxies.java:176)
> at org.apache.hadoop.hdfs.DFSClient.(DFSClient.java:678)
> at org.apache.hadoop.hdfs.DFSClient.(DFSClient.java:619)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem.initialize(DistributedFileSystem.java:149)
> at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2653)
> at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:92)
> at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2687)
> at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2669)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:371)
> at org.apache.hadoop.fs.Path.getFileSystem(Path.java:295)
> at
> org.apache.hadoop.hbase.util.CoprocessorClassLoader.init(CoprocessorClassLoader.java:165)
> at
> org.apache.hadoop.hbase.util.CoprocessorClassLoader.getClassLoader(CoprocessorClassLoader.java:250)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.load(CoprocessorHost.java:194)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.loadTableCoprocessors(RegionCoprocessorHost.java:352)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.(RegionCoprocessorHost.java:240)
> at org.apache.hadoop.hbase.regionserver.HRegion.(HRegion.java:749)
> at org.apache.hadoop.hbase.regionserver.HRegion.(HRegion.java:657)
> at sun.reflect.GeneratedConstructorAccessor13.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.apache.hadoop.hbase.regionserver.HRegion.newHRegion(HRegion.java:6727)
> at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7037)
> at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7009)
> at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6965)
> at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6916)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:362)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:129){code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-22169) Coprocessor path wrong then Region open failed cause memory leak
[
https://issues.apache.org/jira/browse/HBASE-22169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bing Xiao reassigned HBASE-22169:
-
Assignee: Bing Xiao
> Coprocessor path wrong then Region open failed cause memory leak
>
>
> Key: HBASE-22169
> URL: https://issues.apache.org/jira/browse/HBASE-22169
> Project: HBase
> Issue Type: Bug
>Reporter: Bing Xiao
>Assignee: Bing Xiao
>Priority: Major
>
> By coprocessor path wrong region will open failed, MetricsRegionWrapperImpl
> is already init and not close, cause memory leak;
> {code:java}
> 2019-02-21 15:41:32,929 ERROR
> [RS_OPEN_REGION-hb-2zedsc3fxjn12dl6u-005:16020-7]
> regionserver.RegionCoprocessorHost(362): Failed to load coprocessor
> org.apache.kylin.storage.hbase.cube.v2.coprocessor.endpoint.CubeVisitService
> java.lang.IllegalArgumentException: java.net.UnknownHostException: emr-cluster
> at
> org.apache.hadoop.security.SecurityUtil.buildTokenService(SecurityUtil.java:378)
> at
> org.apache.hadoop.hdfs.NameNodeProxies.createNonHAProxy(NameNodeProxies.java:310)
> at
> org.apache.hadoop.hdfs.NameNodeProxies.createProxy(NameNodeProxies.java:176)
> at org.apache.hadoop.hdfs.DFSClient.(DFSClient.java:678)
> at org.apache.hadoop.hdfs.DFSClient.(DFSClient.java:619)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem.initialize(DistributedFileSystem.java:149)
> at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2653)
> at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:92)
> at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2687)
> at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2669)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:371)
> at org.apache.hadoop.fs.Path.getFileSystem(Path.java:295)
> at
> org.apache.hadoop.hbase.util.CoprocessorClassLoader.init(CoprocessorClassLoader.java:165)
> at
> org.apache.hadoop.hbase.util.CoprocessorClassLoader.getClassLoader(CoprocessorClassLoader.java:250)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.load(CoprocessorHost.java:194)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.loadTableCoprocessors(RegionCoprocessorHost.java:352)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.(RegionCoprocessorHost.java:240)
> at org.apache.hadoop.hbase.regionserver.HRegion.(HRegion.java:749)
> at org.apache.hadoop.hbase.regionserver.HRegion.(HRegion.java:657)
> at sun.reflect.GeneratedConstructorAccessor13.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.apache.hadoop.hbase.regionserver.HRegion.newHRegion(HRegion.java:6727)
> at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7037)
> at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7009)
> at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6965)
> at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6916)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:362)
> at
> org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:129){code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22169) Coprocessor path wrong then Region open failed cause memory leak
[
https://issues.apache.org/jira/browse/HBASE-22169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bing Xiao updated HBASE-22169:
--
Description:
By coprocessor path wrong region will open failed, MetricsRegionWrapperImpl is
already init and not close, cause memory leak;
{code:java}
2019-02-21 15:41:32,929 ERROR [RS_OPEN_REGION-hb-2zedsc3fxjn12dl6u-005:16020-7]
regionserver.RegionCoprocessorHost(362): Failed to load coprocessor
org.apache.kylin.storage.hbase.cube.v2.coprocessor.endpoint.CubeVisitService
java.lang.IllegalArgumentException: java.net.UnknownHostException: emr-cluster
at
org.apache.hadoop.security.SecurityUtil.buildTokenService(SecurityUtil.java:378)
at
org.apache.hadoop.hdfs.NameNodeProxies.createNonHAProxy(NameNodeProxies.java:310)
at org.apache.hadoop.hdfs.NameNodeProxies.createProxy(NameNodeProxies.java:176)
at org.apache.hadoop.hdfs.DFSClient.(DFSClient.java:678)
at org.apache.hadoop.hdfs.DFSClient.(DFSClient.java:619)
at
org.apache.hadoop.hdfs.DistributedFileSystem.initialize(DistributedFileSystem.java:149)
at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2653)
at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:92)
at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2687)
at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2669)
at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:371)
at org.apache.hadoop.fs.Path.getFileSystem(Path.java:295)
at
org.apache.hadoop.hbase.util.CoprocessorClassLoader.init(CoprocessorClassLoader.java:165)
at
org.apache.hadoop.hbase.util.CoprocessorClassLoader.getClassLoader(CoprocessorClassLoader.java:250)
at
org.apache.hadoop.hbase.coprocessor.CoprocessorHost.load(CoprocessorHost.java:194)
at
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.loadTableCoprocessors(RegionCoprocessorHost.java:352)
at
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.(RegionCoprocessorHost.java:240)
at org.apache.hadoop.hbase.regionserver.HRegion.(HRegion.java:749)
at org.apache.hadoop.hbase.regionserver.HRegion.(HRegion.java:657)
at sun.reflect.GeneratedConstructorAccessor13.newInstance(Unknown Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.hadoop.hbase.regionserver.HRegion.newHRegion(HRegion.java:6727)
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7037)
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7009)
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6965)
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6916)
at
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:362)
at
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:129){code}
was:
By coprocessor path wrong region will open failed, MetricsRegionWrapperImpl is
already init and not close, cause memory leak;
> Coprocessor path wrong then Region open failed cause memory leak
>
>
> Key: HBASE-22169
> URL: https://issues.apache.org/jira/browse/HBASE-22169
> Project: HBase
> Issue Type: Bug
>Reporter: Bing Xiao
>Priority: Major
>
> By coprocessor path wrong region will open failed, MetricsRegionWrapperImpl
> is already init and not close, cause memory leak;
> {code:java}
> 2019-02-21 15:41:32,929 ERROR
> [RS_OPEN_REGION-hb-2zedsc3fxjn12dl6u-005:16020-7]
> regionserver.RegionCoprocessorHost(362): Failed to load coprocessor
> org.apache.kylin.storage.hbase.cube.v2.coprocessor.endpoint.CubeVisitService
> java.lang.IllegalArgumentException: java.net.UnknownHostException: emr-cluster
> at
> org.apache.hadoop.security.SecurityUtil.buildTokenService(SecurityUtil.java:378)
> at
> org.apache.hadoop.hdfs.NameNodeProxies.createNonHAProxy(NameNodeProxies.java:310)
> at
> org.apache.hadoop.hdfs.NameNodeProxies.createProxy(NameNodeProxies.java:176)
> at org.apache.hadoop.hdfs.DFSClient.(DFSClient.java:678)
> at org.apache.hadoop.hdfs.DFSClient.(DFSClient.java:619)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem.initialize(DistributedFileSystem.java:149)
> at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2653)
> at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:92)
> at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2687)
> at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2669)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:371)
> at org.apache.hadoop.fs.Path.getFileSystem(Path.java:295)
> at
> org.apache.hadoop.hbase.util.CoprocessorClassLoader.init(CoprocessorClassLoader.java:165)
> at
> org.apache.hadoop.hbase.util.Copr
[jira] [Updated] (HBASE-22169) Coprocessor path wrong then Region open failed cause memory leak
[
https://issues.apache.org/jira/browse/HBASE-22169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bing Xiao updated HBASE-22169:
--
Description:
By coprocessor path wrong region will open failed, MetricsRegionWrapperImpl is
already init and not close, cause memory leak;
was:
By coprocessor path wrong region will open failed, MetricsRegionWrapperImpl is
already init and not close, cause memory leak;
{code:java}
2019-02-21 15:41:32,929 ERROR [RS_OPEN_REGION-hb-2zedsc3fxjn12dl6u-005:16020-7]
regionserver.RegionCoprocessorHost(362): Failed to load coprocessor
org.apache.kylin.storage.hbase.cube.v2.coprocessor.endpoint.CubeVisitService
java.lang.IllegalArgumentException: java.net.UnknownHostException: emr-cluster
at
org.apache.hadoop.security.SecurityUtil.buildTokenService(SecurityUtil.java:378)
at
org.apache.hadoop.hdfs.NameNodeProxies.createNonHAProxy(NameNodeProxies.java:310)
at org.apache.hadoop.hdfs.NameNodeProxies.createProxy(NameNodeProxies.java:176)
at org.apache.hadoop.hdfs.DFSClient.(DFSClient.java:678)
at org.apache.hadoop.hdfs.DFSClient.(DFSClient.java:619)
at
org.apache.hadoop.hdfs.DistributedFileSystem.initialize(DistributedFileSystem.java:149)
at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2653)
at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:92)
at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2687)
at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2669)
at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:371)
at org.apache.hadoop.fs.Path.getFileSystem(Path.java:295)
at
org.apache.hadoop.hbase.util.CoprocessorClassLoader.init(CoprocessorClassLoader.java:165)
at
org.apache.hadoop.hbase.util.CoprocessorClassLoader.getClassLoader(CoprocessorClassLoader.java:250)
at
org.apache.hadoop.hbase.coprocessor.CoprocessorHost.load(CoprocessorHost.java:194)
at
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.loadTableCoprocessors(RegionCoprocessorHost.java:352)
at
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.(RegionCoprocessorHost.java:240)
at org.apache.hadoop.hbase.regionserver.HRegion.(HRegion.java:749)
at org.apache.hadoop.hbase.regionserver.HRegion.(HRegion.java:657)
at sun.reflect.GeneratedConstructorAccessor13.newInstance(Unknown Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.hadoop.hbase.regionserver.HRegion.newHRegion(HRegion.java:6727)
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7037)
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7009)
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6965)
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6916)
at
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:362)
at
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:129){code}
> Coprocessor path wrong then Region open failed cause memory leak
>
>
> Key: HBASE-22169
> URL: https://issues.apache.org/jira/browse/HBASE-22169
> Project: HBase
> Issue Type: Bug
>Reporter: Bing Xiao
>Priority: Major
>
> By coprocessor path wrong region will open failed, MetricsRegionWrapperImpl
> is already init and not close, cause memory leak;
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-22169) Coprocessor path wrong then Region open failed cause memory leak
Bing Xiao created HBASE-22169:
-
Summary: Coprocessor path wrong then Region open failed cause
memory leak
Key: HBASE-22169
URL: https://issues.apache.org/jira/browse/HBASE-22169
Project: HBase
Issue Type: Bug
Reporter: Bing Xiao
By coprocessor path wrong region will open failed, MetricsRegionWrapperImpl is
already init and not close, cause memory leak;
{code:java}
2019-02-21 15:41:32,929 ERROR [RS_OPEN_REGION-hb-2zedsc3fxjn12dl6u-005:16020-7]
regionserver.RegionCoprocessorHost(362): Failed to load coprocessor
org.apache.kylin.storage.hbase.cube.v2.coprocessor.endpoint.CubeVisitService
java.lang.IllegalArgumentException: java.net.UnknownHostException: emr-cluster
at
org.apache.hadoop.security.SecurityUtil.buildTokenService(SecurityUtil.java:378)
at
org.apache.hadoop.hdfs.NameNodeProxies.createNonHAProxy(NameNodeProxies.java:310)
at org.apache.hadoop.hdfs.NameNodeProxies.createProxy(NameNodeProxies.java:176)
at org.apache.hadoop.hdfs.DFSClient.(DFSClient.java:678)
at org.apache.hadoop.hdfs.DFSClient.(DFSClient.java:619)
at
org.apache.hadoop.hdfs.DistributedFileSystem.initialize(DistributedFileSystem.java:149)
at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2653)
at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:92)
at org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2687)
at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2669)
at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:371)
at org.apache.hadoop.fs.Path.getFileSystem(Path.java:295)
at
org.apache.hadoop.hbase.util.CoprocessorClassLoader.init(CoprocessorClassLoader.java:165)
at
org.apache.hadoop.hbase.util.CoprocessorClassLoader.getClassLoader(CoprocessorClassLoader.java:250)
at
org.apache.hadoop.hbase.coprocessor.CoprocessorHost.load(CoprocessorHost.java:194)
at
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.loadTableCoprocessors(RegionCoprocessorHost.java:352)
at
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.(RegionCoprocessorHost.java:240)
at org.apache.hadoop.hbase.regionserver.HRegion.(HRegion.java:749)
at org.apache.hadoop.hbase.regionserver.HRegion.(HRegion.java:657)
at sun.reflect.GeneratedConstructorAccessor13.newInstance(Unknown Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.hadoop.hbase.regionserver.HRegion.newHRegion(HRegion.java:6727)
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7037)
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7009)
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6965)
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6916)
at
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:362)
at
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:129){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22155) Move 2.2.0 on to hbase-thirdparty-2.2.0
[
https://issues.apache.org/jira/browse/HBASE-22155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810521#comment-16810521
]
Hadoop QA commented on HBASE-22155:
---
| (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 7s{color}
| {color:red} HBASE-22155 does not apply to 2. Rebase required? Wrong Branch?
See https://yetus.apache.org/documentation/0.8.0/precommit-patchnames for help.
{color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-22155 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964953/HBASE-22155.branch-2.2.003.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/16658/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Move 2.2.0 on to hbase-thirdparty-2.2.0
> ---
>
> Key: HBASE-22155
> URL: https://issues.apache.org/jira/browse/HBASE-22155
> Project: HBase
> Issue Type: Sub-task
> Components: thirdparty
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
> Attachments: HBASE-22155-branch-2.2-001.patch,
> HBASE-22155-branch-2.2-001.patch, HBASE-22155-branch-2.2-001.patch,
> HBASE-22155-branch-2.2-001.patch, HBASE-22155.branch-2.2.001.patch,
> HBASE-22155.branch-2.2.002.patch, HBASE-22155.branch-2.2.003.patch
>
>
> hbase-thirdparty-2.2.0 was just released. The 2.2.0 RM ([~zghaobac]) gave his
> blessing in parent issue that 2.2.0 should use thirdparty 2.2.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22155) Move 2.2.0 on to hbase-thirdparty-2.2.0
[ https://issues.apache.org/jira/browse/HBASE-22155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-22155: -- Attachment: HBASE-22155.branch-2.2.003.patch > Move 2.2.0 on to hbase-thirdparty-2.2.0 > --- > > Key: HBASE-22155 > URL: https://issues.apache.org/jira/browse/HBASE-22155 > Project: HBase > Issue Type: Sub-task > Components: thirdparty >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-22155-branch-2.2-001.patch, > HBASE-22155-branch-2.2-001.patch, HBASE-22155-branch-2.2-001.patch, > HBASE-22155-branch-2.2-001.patch, HBASE-22155.branch-2.2.001.patch, > HBASE-22155.branch-2.2.002.patch, HBASE-22155.branch-2.2.003.patch > > > hbase-thirdparty-2.2.0 was just released. The 2.2.0 RM ([~zghaobac]) gave his > blessing in parent issue that 2.2.0 should use thirdparty 2.2.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22127) Ensure that the block cached in the LRUBlockCache offheap is allocated from heap
[
https://issues.apache.org/jira/browse/HBASE-22127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810489#comment-16810489
]
Hadoop QA commented on HBASE-22127:
---
| (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: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} HBASE-21879 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
28s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
24s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
32s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
41s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
41s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
5s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
55s{color} | {color:green} HBASE-21879 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
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
29s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 2m 50s{color}
| {color:red} hbase-server generated 1 new + 193 unchanged - 1 fixed = 194
total (was 194) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
26s{color} | {color:red} hbase-common: The patch generated 1 new + 0 unchanged
- 0 fixed = 1 total (was 0) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
14s{color} | {color:green} hbase-server: The patch generated 0 new + 137
unchanged - 4 fixed = 137 total (was 141) {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
41s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 40s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
43s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}140m
48s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
45s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}191m 10s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-22127 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964938/HBASE-22127.HBASE-21879.v6.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 575c7502302c 4.4.0-131-generic #157~14.04.1-Ubuntu SMP
[jira] [Updated] (HBASE-22159) ByteBufferIOEngine should support write off-heap ByteBuff to the bufferArray
[
https://issues.apache.org/jira/browse/HBASE-22159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zheng Hu updated HBASE-22159:
-
Attachment: HBASE-22159.HBASE-21879.v4.patch
> ByteBufferIOEngine should support write off-heap ByteBuff to the bufferArray
>
>
> Key: HBASE-22159
> URL: https://issues.apache.org/jira/browse/HBASE-22159
> Project: HBase
> Issue Type: Sub-task
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Attachments: HBASE-22159.HBASE-21879.v1.patch,
> HBASE-22159.HBASE-21879.v2.patch, HBASE-22159.HBASE-21879.v3.patch,
> HBASE-22159.HBASE-21879.v4.patch
>
>
> In ByteBufferIOEngine , we have the assert:
> {code}
> @Override
> public void write(ByteBuffer srcBuffer, long offset) throws IOException {
> assert srcBuffer.hasArray();
> bufferArray.putMultiple(offset, srcBuffer.remaining(), srcBuffer.array(),
> srcBuffer.arrayOffset());
> }
> @Override
> public void write(ByteBuff srcBuffer, long offset) throws IOException {
> // When caching block into BucketCache there will be single buffer
> backing for this HFileBlock.
> // This will work for now. But from the DFS itself if we get DBB then
> this may not hold true.
> assert srcBuffer.hasArray();
> bufferArray.putMultiple(offset, srcBuffer.remaining(), srcBuffer.array(),
> srcBuffer.arrayOffset());
> }
> {code}
> Should remove the assert, and allow to write off-heap ByteBuff to bufferArray.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20912) Add import order config in dev support for eclipse
[ https://issues.apache.org/jira/browse/HBASE-20912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810448#comment-16810448 ] Andrew Purtell commented on HBASE-20912: I'll commit tomorrow. We could use a small note in the developer doc in the online book pointing out this file and providing instructions on how to install it. If there is time and interest. (smile) > Add import order config in dev support for eclipse > -- > > Key: HBASE-20912 > URL: https://issues.apache.org/jira/browse/HBASE-20912 > Project: HBase > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal >Priority: Major > Attachments: eclipse.importorder > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20912) Add import order config in dev support for eclipse
[ https://issues.apache.org/jira/browse/HBASE-20912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810446#comment-16810446 ] Tak Lon (Stephen) Wu commented on HBASE-20912: -- Thanks Andrew! > Add import order config in dev support for eclipse > -- > > Key: HBASE-20912 > URL: https://issues.apache.org/jira/browse/HBASE-20912 > Project: HBase > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal >Priority: Major > Attachments: eclipse.importorder > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22127) Ensure that the block cached in the LRUBlockCache offheap is allocated from heap
[ https://issues.apache.org/jira/browse/HBASE-22127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22127: - Attachment: HBASE-22127.HBASE-21879.v6.patch > Ensure that the block cached in the LRUBlockCache offheap is allocated from > heap > > > Key: HBASE-22127 > URL: https://issues.apache.org/jira/browse/HBASE-22127 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-22127.HBASE-21879.v1.patch, > HBASE-22127.HBASE-21879.v2.patch, HBASE-22127.HBASE-21879.v3.patch, > HBASE-22127.HBASE-21879.v4.patch, HBASE-22127.HBASE-21879.v5.patch, > HBASE-22127.HBASE-21879.v6.patch > > > In here [1], [~anoop.hbase] pointed out an crtial problem , I pasted here: > bq. So if we read from HDFS into a pooled BB and then give to LRU cache for > caching (ya mostly cache on read might be true) we will cache the block which > is backed by this pooled DBB? Unless the block is evicted , this BB wont go > back to pool. I think this is some thing we can not livw with !! For LRU > cache the sizing itself is based on what % of heap size we can grow. But here > in effect we are occupying the off heap space for the cached blocks. All the > sizing assumptions and calc going out of control ! > It's indeed an big problem here. so we can only make the block ref to an heap > area if we use LRUCache (both LruBlockCache and CombinedBlockCache case). Or > we can also make the lru cache offheap ? > I think we can introduce an switch indicate that whether the lru block cache > offheap or not, if heap, then coping those bytes from ByteBuff to heap. > https://reviews.apache.org/r/70153/diff/6?file=2133545#file2133545line398 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20912) Add import order config in dev support for eclipse
[ https://issues.apache.org/jira/browse/HBASE-20912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810440#comment-16810440 ] Andrew Purtell commented on HBASE-20912: Ok, I'll commit that version, crediting you both. > Add import order config in dev support for eclipse > -- > > Key: HBASE-20912 > URL: https://issues.apache.org/jira/browse/HBASE-20912 > Project: HBase > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal >Priority: Major > Attachments: eclipse.importorder > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[
https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810419#comment-16810419
]
Hudson commented on HBASE-22152:
Results for branch branch-2.1
[build #1022 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1022/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1022//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1022//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1022//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(x) {color:red}-1 client integration test{color}
--Failed when running client tests on top of Hadoop 2. [see log for
details|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/1022//artifact/output-integration/hadoop-2.log].
(note that this means we didn't run on Hadoop 3)
> Create a jenkins file for yetus to processing GitHub PR
> ---
>
> Key: HBASE-22152
> URL: https://issues.apache.org/jira/browse/HBASE-22152
> Project: HBase
> Issue Type: Sub-task
> Components: build
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1,
> 1.2.12, 2.1.5
>
> Attachments: HBASE-22152-v1.patch, HBASE-22152.patch
>
>
> I think we can just copy the jenkinsfile from the hadoop project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22155) Move 2.2.0 on to hbase-thirdparty-2.2.0
[
https://issues.apache.org/jira/browse/HBASE-22155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810411#comment-16810411
]
Hadoop QA commented on HBASE-22155:
---
| (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 7s{color}
| {color:red} HBASE-22155 does not apply to 2. Rebase required? Wrong Branch?
See https://yetus.apache.org/documentation/0.8.0/precommit-patchnames for help.
{color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-22155 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964934/HBASE-22155.branch-2.2.002.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/16655/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Move 2.2.0 on to hbase-thirdparty-2.2.0
> ---
>
> Key: HBASE-22155
> URL: https://issues.apache.org/jira/browse/HBASE-22155
> Project: HBase
> Issue Type: Sub-task
> Components: thirdparty
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
> Attachments: HBASE-22155-branch-2.2-001.patch,
> HBASE-22155-branch-2.2-001.patch, HBASE-22155-branch-2.2-001.patch,
> HBASE-22155-branch-2.2-001.patch, HBASE-22155.branch-2.2.001.patch,
> HBASE-22155.branch-2.2.002.patch
>
>
> hbase-thirdparty-2.2.0 was just released. The 2.2.0 RM ([~zghaobac]) gave his
> blessing in parent issue that 2.2.0 should use thirdparty 2.2.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20912) Add import order config in dev support for eclipse
[
https://issues.apache.org/jira/browse/HBASE-20912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810410#comment-16810410
]
Ankit Singhal edited comment on HBASE-20912 at 4/4/19 11:34 PM:
{quote}Meanwhile Tak Lon (Stephen) Wu's patch adds it as
{quote}
{code:java}
#Organize Import Order
3=org.apache.hadoop.hbase.shaded
2=org.apache.hbase.thirdparty
1=
0=\#
{code}
I think this one is better, "0=\#" means that all static imports to be listed
first in order. (intellij does it by default but eclipse generally put it at
last).
was (Author: an...@apache.org):
bq. Meanwhile Tak Lon (Stephen) Wu's patch adds it as
{code}
#Organize Import Order
3=org.apache.hadoop.hbase.shaded
2=org.apache.hbase.thirdparty
1=
0=\\#
{code}
I think this one is better, "0=\#" means that all static imports to be listed
first in order. (intellij does it by default but eclipse generally put it at
last).
> Add import order config in dev support for eclipse
> --
>
> Key: HBASE-20912
> URL: https://issues.apache.org/jira/browse/HBASE-20912
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Attachments: eclipse.importorder
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20912) Add import order config in dev support for eclipse
[
https://issues.apache.org/jira/browse/HBASE-20912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810410#comment-16810410
]
Ankit Singhal commented on HBASE-20912:
---
bq. Meanwhile Tak Lon (Stephen) Wu's patch adds it as
{code}
#Organize Import Order
3=org.apache.hadoop.hbase.shaded
2=org.apache.hbase.thirdparty
1=
0=\#
{code}
I think this one is better, "0=\#" means that all static imports to be listed
first in order. (intellij does it by default but eclipse generally put it at
last).
> Add import order config in dev support for eclipse
> --
>
> Key: HBASE-20912
> URL: https://issues.apache.org/jira/browse/HBASE-20912
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Attachments: eclipse.importorder
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22155) Move 2.2.0 on to hbase-thirdparty-2.2.0
[ https://issues.apache.org/jira/browse/HBASE-22155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810409#comment-16810409 ] stack commented on HBASE-22155: --- We're interrupted while waiting on disable of table at end of a test. Happens sporadically. .002 adds more info on interrupt exception. See if that helps. > Move 2.2.0 on to hbase-thirdparty-2.2.0 > --- > > Key: HBASE-22155 > URL: https://issues.apache.org/jira/browse/HBASE-22155 > Project: HBase > Issue Type: Sub-task > Components: thirdparty >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-22155-branch-2.2-001.patch, > HBASE-22155-branch-2.2-001.patch, HBASE-22155-branch-2.2-001.patch, > HBASE-22155-branch-2.2-001.patch, HBASE-22155.branch-2.2.001.patch, > HBASE-22155.branch-2.2.002.patch > > > hbase-thirdparty-2.2.0 was just released. The 2.2.0 RM ([~zghaobac]) gave his > blessing in parent issue that 2.2.0 should use thirdparty 2.2.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20912) Add import order config in dev support for eclipse
[
https://issues.apache.org/jira/browse/HBASE-20912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810410#comment-16810410
]
Ankit Singhal edited comment on HBASE-20912 at 4/4/19 11:33 PM:
bq. Meanwhile Tak Lon (Stephen) Wu's patch adds it as
{code}
#Organize Import Order
3=org.apache.hadoop.hbase.shaded
2=org.apache.hbase.thirdparty
1=
0=\\#
{code}
I think this one is better, "0=\#" means that all static imports to be listed
first in order. (intellij does it by default but eclipse generally put it at
last).
was (Author: an...@apache.org):
bq. Meanwhile Tak Lon (Stephen) Wu's patch adds it as
{code}
#Organize Import Order
3=org.apache.hadoop.hbase.shaded
2=org.apache.hbase.thirdparty
1=
0=\#
{code}
I think this one is better, "0=\#" means that all static imports to be listed
first in order. (intellij does it by default but eclipse generally put it at
last).
> Add import order config in dev support for eclipse
> --
>
> Key: HBASE-20912
> URL: https://issues.apache.org/jira/browse/HBASE-20912
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Attachments: eclipse.importorder
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22155) Move 2.2.0 on to hbase-thirdparty-2.2.0
[ https://issues.apache.org/jira/browse/HBASE-22155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-22155: -- Attachment: HBASE-22155.branch-2.2.002.patch > Move 2.2.0 on to hbase-thirdparty-2.2.0 > --- > > Key: HBASE-22155 > URL: https://issues.apache.org/jira/browse/HBASE-22155 > Project: HBase > Issue Type: Sub-task > Components: thirdparty >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-22155-branch-2.2-001.patch, > HBASE-22155-branch-2.2-001.patch, HBASE-22155-branch-2.2-001.patch, > HBASE-22155-branch-2.2-001.patch, HBASE-22155.branch-2.2.001.patch, > HBASE-22155.branch-2.2.002.patch > > > hbase-thirdparty-2.2.0 was just released. The 2.2.0 RM ([~zghaobac]) gave his > blessing in parent issue that 2.2.0 should use thirdparty 2.2.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22168) proc WALs with non-corrupted-but-"corrupted" procedures block WAL archiving forever
[
https://issues.apache.org/jira/browse/HBASE-22168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HBASE-22168:
-
Affects Version/s: 3.0.0
> proc WALs with non-corrupted-but-"corrupted" procedures block WAL archiving
> forever
> ---
>
> Key: HBASE-22168
> URL: https://issues.apache.org/jira/browse/HBASE-22168
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Sergey Shelukhin
>Priority: Critical
>
> I've reported the bug before where we get these messages when loading proc WAL
> {noformat}
> 2019-04-04 14:43:00,424 ERROR [master/...:becomeActiveMaster]
> wal.WALProcedureTree: Missing stack id 43459, max stack id is 43460, root
> procedure is Procedure(pid=43645, ppid=-1,
> class=org.apache.hadoop.hbase.master.procedure.ServerCrashProcedure)
> {noformat}
> resulting in
> {noformat}
> 2019-04-04 14:43:16,176 ERROR [...:17000:becomeActiveMaster]
> procedure2.ProcedureExecutor: Corrupt pid=43645,
> state=WAITING:SERVER_CRASH_FINISH, hasLock=false; ServerCrashProcedure
> server=..., splitWal=true, meta=false
> {noformat}
> There is no actual corruption in the file, so it never gets moved to
> corrupted files.
> However, there's no accounting for these kind of procedures in the tracker as
> far as I can tell (I didn't spend a lot of time looking at the code though)
> so as a result we get 100s of proc wals that are stuck forever because of
> some ancient file with these WALs; that causes master startup to take a long
> time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20912) Add import order config in dev support for eclipse
[
https://issues.apache.org/jira/browse/HBASE-20912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810402#comment-16810402
]
Andrew Purtell commented on HBASE-20912:
The patch here adds file eclipse.importorder as
{noformat}
#Organize Import Order
#Thu Jul 19 12:47:34 PDT 2018
2=org.apache.hadoop.hbase.shaded
1=org.apache.hbase.thirdparty
0=
{noformat}
Meanwhile [~taklwu]'s patch adds it as
{noformat}
#Organize Import Order
3=org.apache.hadoop.hbase.shaded
2=org.apache.hbase.thirdparty
1=
0=\#
{noformat}
Can someone explain the difference? Happy commit the blessed version of this
file.
> Add import order config in dev support for eclipse
> --
>
> Key: HBASE-20912
> URL: https://issues.apache.org/jira/browse/HBASE-20912
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Attachments: eclipse.importorder
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22149) HBOSS: A FileSystem implementation to provide HBase's required semantics
[ https://issues.apache.org/jira/browse/HBASE-22149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810403#comment-16810403 ] Vladimir Rodionov commented on HBASE-22149: --- [~mackrorysd], you can take a look at [www.min.io|http://minio] for S3 local testing. > HBOSS: A FileSystem implementation to provide HBase's required semantics > > > Key: HBASE-22149 > URL: https://issues.apache.org/jira/browse/HBASE-22149 > Project: HBase > Issue Type: New Feature > Components: Filesystem Integration >Reporter: Sean Mackrory >Assignee: Sean Mackrory >Priority: Critical > Attachments: HBASE-22149-hadoop.patch, HBASE-22149-hbase.patch > > > (Have been using the name HBOSS for HBase / Object Store Semantics) > I've had some thoughts about how to solve the problem of running HBase on > object stores. There has been some thought in the past about adding the > required semantics to S3Guard, but I have some concerns about that. First, > it's mixing complicated solutions to different problems (bridging the gap > between a flat namespace and a hierarchical namespace vs. solving > inconsistency). Second, it's S3-specific, whereas other objects stores could > use virtually identical solutions. And third, we can't do things like atomic > renames in a true sense. There would have to be some trade-offs specific to > HBase's needs and it's better if we can solve that in an HBase-specific > module without mixing all that logic in with the rest of S3A. > Ideas to solve this above the FileSystem layer have been proposed and > considered (HBASE-20431, for one), and maybe that's the right way forward > long-term, but it certainly seems to be a hard problem and hasn't been done > yet. But I don't know enough of all the internal considerations to make much > of a judgment on that myself. > I propose a FileSystem implementation that wraps another FileSystem instance > and provides locking of FileSystem operations to ensure correct semantics. > Locking could quite possibly be done on the same ZooKeeper ensemble as an > HBase cluster already uses (I'm sure there are some performance > considerations here that deserve more attention). I've put together a > proof-of-concept on which I've tested some aspects of atomic renames and > atomic file creates. Both of these tests fail reliably on a naked s3a > instance. I've also done a small YCSB run against a small cluster to sanity > check other functionality and was successful. I will post the patch, and my > laundry list of things that still need work. The WAL is still placed on HDFS, > but the HBase root directory is otherwise on S3. > Note that my prototype is built on Hadoop's source tree right now. That's > purely for my convenience in putting it together quickly, as that's where I > mostly work. I actually think long-term, if this is accepted as a good > solution, it makes sense to live in HBase (or it's own repository). It only > depends on stable, public APIs in Hadoop and is targeted entirely at HBase's > needs, so it should be able to iterate on the HBase community's terms alone. > Another idea [~ste...@apache.org] proposed to me is that of an inode-based > FileSystem that keeps hierarchical metadata in a more appropriate store that > would allow the required transactions (maybe a special table in HBase could > provide that store itself for other tables), and stores the underlying files > with unique identifiers on S3. This allows renames to actually become fast > instead of just large atomic operations. It does however place a strong > dependency on the metadata store. I have not explored this idea much. My > current proof-of-concept has been pleasantly simple, so I think it's the > right solution unless it proves unable to provide the required performance > characteristics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22168) proc WALs with non-corrupted-but-"corrupted" procedures block WAL archiving forever
[
https://issues.apache.org/jira/browse/HBASE-22168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HBASE-22168:
-
Summary: proc WALs with non-corrupted-but-"corrupted" procedures block WAL
archiving forever (was: proc WALs with non-corrupted-but-"corrupted" block WAL
archiving forever)
> proc WALs with non-corrupted-but-"corrupted" procedures block WAL archiving
> forever
> ---
>
> Key: HBASE-22168
> URL: https://issues.apache.org/jira/browse/HBASE-22168
> Project: HBase
> Issue Type: Bug
>Reporter: Sergey Shelukhin
>Priority: Critical
>
> I've reported the bug before where we get these messages when loading proc WAL
> {noformat}
> 2019-04-04 14:43:00,424 ERROR [master/...:becomeActiveMaster]
> wal.WALProcedureTree: Missing stack id 43459, max stack id is 43460, root
> procedure is Procedure(pid=43645, ppid=-1,
> class=org.apache.hadoop.hbase.master.procedure.ServerCrashProcedure)
> {noformat}
> resulting in
> {noformat}
> 2019-04-04 14:43:16,176 ERROR [...:17000:becomeActiveMaster]
> procedure2.ProcedureExecutor: Corrupt pid=43645,
> state=WAITING:SERVER_CRASH_FINISH, hasLock=false; ServerCrashProcedure
> server=..., splitWal=true, meta=false
> {noformat}
> There is no actual corruption in the file, so it never gets moved to
> corrupted files.
> However, there's no accounting for these kind of procedures in the tracker as
> far as I can tell (I didn't spend a lot of time looking at the code though)
> so as a result we get 100s of proc wals that are stuck forever because of
> some ancient file with these WALs; that causes master startup to take a long
> time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-22168) proc WALs with non-corrupted-but-"corrupted" block WAL archiving forever
Sergey Shelukhin created HBASE-22168:
Summary: proc WALs with non-corrupted-but-"corrupted" block WAL
archiving forever
Key: HBASE-22168
URL: https://issues.apache.org/jira/browse/HBASE-22168
Project: HBase
Issue Type: Bug
Reporter: Sergey Shelukhin
I've reported the bug before where we get these messages when loading proc WAL
{noformat}
2019-04-04 14:43:00,424 ERROR [master/...:becomeActiveMaster]
wal.WALProcedureTree: Missing stack id 43459, max stack id is 43460, root
procedure is Procedure(pid=43645, ppid=-1,
class=org.apache.hadoop.hbase.master.procedure.ServerCrashProcedure)
{noformat}
resulting in
{noformat}
2019-04-04 14:43:16,176 ERROR [...:17000:becomeActiveMaster]
procedure2.ProcedureExecutor: Corrupt pid=43645,
state=WAITING:SERVER_CRASH_FINISH, hasLock=false; ServerCrashProcedure
server=..., splitWal=true, meta=false
{noformat}
There is no actual corruption in the file, so it never gets moved to corrupted
files.
However, there's no accounting for these kind of procedures in the tracker as
far as I can tell (I didn't spend a lot of time looking at the code though) so
as a result we get 100s of proc wals that are stuck forever because of some
ancient file with these WALs; that causes master startup to take a long time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22143) HBCK2 setRegionState command
[
https://issues.apache.org/jira/browse/HBASE-22143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated HBASE-22143:
---
Release Note:
Adds a new feature to HBCK2: setRegionState.
Given the encoded name of a Region, this command allows you to change the state
of that Region recorded in Meta.
[~wchevreuil], I've added a basic release note. Please feel free to beef it up
as you see fit.
> HBCK2 setRegionState command
>
>
> Key: HBASE-22143
> URL: https://issues.apache.org/jira/browse/HBASE-22143
> Project: HBase
> Issue Type: New Feature
> Components: hbase-operator-tools, hbck2
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Minor
> Fix For: hbck2-1.0.0
>
> Attachments: HBASE-22143.master.0001.patch,
> HBASE-22143.master.0002.patch, HBASE-22143.master.0003.patch
>
>
> Among some of the current AMv2 issues, we faced situation where some regions
> had state as OPENING in meta, with an RS startcode that was not valid
> anymore. There was no AP running, the region stays permanently being logged
> as IN-Transition on master logs, yet no procedure is really trying to bring
> it online. Current hbck2 unassigns/assigns commands didn't work either, as
> per the exception shown, it expects regions to be in state SPLITTING, SPLIT,
> MERGING, OPEN, or CLOSING:
> {noformat}
> WARN org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure:
> Failed transition, suspend 1secs pid=7093,
> state=RUNNABLE:REGION_TRANSITION_DISPATCH, locked=true; UnassignProcedure
> table=rc_accounts, region=db85127b77fa56f7ad44e2c988e53925,
> server=server1.example.com,16020,1552682193324; rit=OPENING,
> location=server1.example.com,16020,1552682193324; waiting on rectified
> condition fixed by other Procedure or operator intervention
> org.apache.hadoop.hbase.exceptions.UnexpectedStateException: Expected
> [SPLITTING, SPLIT, MERGING, OPEN, CLOSING] so could move to CLOSING but
> current state=OPENING
> at
> org.apache.hadoop.hbase.master.assignment.RegionStates$RegionStateNode.transitionState(RegionStates.java:166)
> at
> org.apache.hadoop.hbase.master.assignment.AssignmentManager.markRegionAsClosing(AssignmentManager.java:1479)
> at
> org.apache.hadoop.hbase.master.assignment.UnassignProcedure.updateTransition(UnassignProcedure.java:212)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:369)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:97)
> at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:957)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1835)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1595){noformat}
> In this specific case, since we know the region is not actually being
> operated by any proc and is not really open anywhere, it's ok to manually set
> it's state to one of those assigns/unassigns can operate on, so this jira
> proposes a new hbck2 command that allows for arbitrarily set a region to a
> given state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HBASE-22143) HBCK2 setRegionState command
[
https://issues.apache.org/jira/browse/HBASE-22143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved HBASE-22143.
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: hbck2-1.0.0
> HBCK2 setRegionState command
>
>
> Key: HBASE-22143
> URL: https://issues.apache.org/jira/browse/HBASE-22143
> Project: HBase
> Issue Type: New Feature
> Components: hbase-operator-tools, hbck2
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Minor
> Fix For: hbck2-1.0.0
>
> Attachments: HBASE-22143.master.0001.patch,
> HBASE-22143.master.0002.patch, HBASE-22143.master.0003.patch
>
>
> Among some of the current AMv2 issues, we faced situation where some regions
> had state as OPENING in meta, with an RS startcode that was not valid
> anymore. There was no AP running, the region stays permanently being logged
> as IN-Transition on master logs, yet no procedure is really trying to bring
> it online. Current hbck2 unassigns/assigns commands didn't work either, as
> per the exception shown, it expects regions to be in state SPLITTING, SPLIT,
> MERGING, OPEN, or CLOSING:
> {noformat}
> WARN org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure:
> Failed transition, suspend 1secs pid=7093,
> state=RUNNABLE:REGION_TRANSITION_DISPATCH, locked=true; UnassignProcedure
> table=rc_accounts, region=db85127b77fa56f7ad44e2c988e53925,
> server=server1.example.com,16020,1552682193324; rit=OPENING,
> location=server1.example.com,16020,1552682193324; waiting on rectified
> condition fixed by other Procedure or operator intervention
> org.apache.hadoop.hbase.exceptions.UnexpectedStateException: Expected
> [SPLITTING, SPLIT, MERGING, OPEN, CLOSING] so could move to CLOSING but
> current state=OPENING
> at
> org.apache.hadoop.hbase.master.assignment.RegionStates$RegionStateNode.transitionState(RegionStates.java:166)
> at
> org.apache.hadoop.hbase.master.assignment.AssignmentManager.markRegionAsClosing(AssignmentManager.java:1479)
> at
> org.apache.hadoop.hbase.master.assignment.UnassignProcedure.updateTransition(UnassignProcedure.java:212)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:369)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:97)
> at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:957)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1835)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1595){noformat}
> In this specific case, since we know the region is not actually being
> operated by any proc and is not really open anywhere, it's ok to manually set
> it's state to one of those assigns/unassigns can operate on, so this jira
> proposes a new hbck2 command that allows for arbitrarily set a region to a
> given state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22143) HBCK2 setRegionState command
[
https://issues.apache.org/jira/browse/HBASE-22143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810345#comment-16810345
]
Josh Elser commented on HBASE-22143:
v3 looks good to me, Wellington! Thanks for the quick iterations today.
Testing locally and will push then.
> HBCK2 setRegionState command
>
>
> Key: HBASE-22143
> URL: https://issues.apache.org/jira/browse/HBASE-22143
> Project: HBase
> Issue Type: New Feature
> Components: hbase-operator-tools, hbck2
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Minor
> Attachments: HBASE-22143.master.0001.patch,
> HBASE-22143.master.0002.patch, HBASE-22143.master.0003.patch
>
>
> Among some of the current AMv2 issues, we faced situation where some regions
> had state as OPENING in meta, with an RS startcode that was not valid
> anymore. There was no AP running, the region stays permanently being logged
> as IN-Transition on master logs, yet no procedure is really trying to bring
> it online. Current hbck2 unassigns/assigns commands didn't work either, as
> per the exception shown, it expects regions to be in state SPLITTING, SPLIT,
> MERGING, OPEN, or CLOSING:
> {noformat}
> WARN org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure:
> Failed transition, suspend 1secs pid=7093,
> state=RUNNABLE:REGION_TRANSITION_DISPATCH, locked=true; UnassignProcedure
> table=rc_accounts, region=db85127b77fa56f7ad44e2c988e53925,
> server=server1.example.com,16020,1552682193324; rit=OPENING,
> location=server1.example.com,16020,1552682193324; waiting on rectified
> condition fixed by other Procedure or operator intervention
> org.apache.hadoop.hbase.exceptions.UnexpectedStateException: Expected
> [SPLITTING, SPLIT, MERGING, OPEN, CLOSING] so could move to CLOSING but
> current state=OPENING
> at
> org.apache.hadoop.hbase.master.assignment.RegionStates$RegionStateNode.transitionState(RegionStates.java:166)
> at
> org.apache.hadoop.hbase.master.assignment.AssignmentManager.markRegionAsClosing(AssignmentManager.java:1479)
> at
> org.apache.hadoop.hbase.master.assignment.UnassignProcedure.updateTransition(UnassignProcedure.java:212)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:369)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:97)
> at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:957)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1835)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1595){noformat}
> In this specific case, since we know the region is not actually being
> operated by any proc and is not really open anywhere, it's ok to manually set
> it's state to one of those assigns/unassigns can operate on, so this jira
> proposes a new hbck2 command that allows for arbitrarily set a region to a
> given state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22155) Move 2.2.0 on to hbase-thirdparty-2.2.0
[ https://issues.apache.org/jira/browse/HBASE-22155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810322#comment-16810322 ] stack commented on HBASE-22155: --- If I run the tests in the build docker image locally, they pass. Let me try real machine... And they pass on it too. So something about hadooqa... > Move 2.2.0 on to hbase-thirdparty-2.2.0 > --- > > Key: HBASE-22155 > URL: https://issues.apache.org/jira/browse/HBASE-22155 > Project: HBase > Issue Type: Sub-task > Components: thirdparty >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-22155-branch-2.2-001.patch, > HBASE-22155-branch-2.2-001.patch, HBASE-22155-branch-2.2-001.patch, > HBASE-22155-branch-2.2-001.patch, HBASE-22155.branch-2.2.001.patch > > > hbase-thirdparty-2.2.0 was just released. The 2.2.0 RM ([~zghaobac]) gave his > blessing in parent issue that 2.2.0 should use thirdparty 2.2.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[
https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810310#comment-16810310
]
Hudson commented on HBASE-22152:
Results for branch branch-2.0
[build #1491 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1491/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1491//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1491//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1491//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Create a jenkins file for yetus to processing GitHub PR
> ---
>
> Key: HBASE-22152
> URL: https://issues.apache.org/jira/browse/HBASE-22152
> Project: HBase
> Issue Type: Sub-task
> Components: build
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1,
> 1.2.12, 2.1.5
>
> Attachments: HBASE-22152-v1.patch, HBASE-22152.patch
>
>
> I think we can just copy the jenkinsfile from the hadoop project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[
https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810300#comment-16810300
]
Hudson commented on HBASE-22152:
Results for branch branch-2
[build #1796 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Create a jenkins file for yetus to processing GitHub PR
> ---
>
> Key: HBASE-22152
> URL: https://issues.apache.org/jira/browse/HBASE-22152
> Project: HBase
> Issue Type: Sub-task
> Components: build
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1,
> 1.2.12, 2.1.5
>
> Attachments: HBASE-22152-v1.patch, HBASE-22152.patch
>
>
> I think we can just copy the jenkinsfile from the hadoop project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22073) /rits.jsp throws an exception if no procedure
[
https://issues.apache.org/jira/browse/HBASE-22073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810298#comment-16810298
]
Hudson commented on HBASE-22073:
Results for branch branch-2
[build #1796 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> /rits.jsp throws an exception if no procedure
> -
>
> Key: HBASE-22073
> URL: https://issues.apache.org/jira/browse/HBASE-22073
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.1.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22073.branch-2.1.patch, HBASE-22073.master.patch
>
>
> I got the following exception in our test environment:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.generated.master.rits_jsp._jspService(rits_jsp.java:101)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...
> {noformat}
> Because {{regionStateNode.getProcedure()}} returns {{null}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22133) Forward port HBASE-22073 "/rits.jsp throws an exception if no procedure" to branch-2.2+
[
https://issues.apache.org/jira/browse/HBASE-22133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810297#comment-16810297
]
Hudson commented on HBASE-22133:
Results for branch branch-2
[build #1796 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Forward port HBASE-22073 "/rits.jsp throws an exception if no procedure" to
> branch-2.2+
> ---
>
> Key: HBASE-22133
> URL: https://issues.apache.org/jira/browse/HBASE-22133
> Project: HBase
> Issue Type: Bug
> Components: UI
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-22133-v1.patch, HBASE-22133.patch
>
>
> The RIT procedure has been changed for branch-2.2+ so we can not use the
> patch for branch-2.1 directly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22157) Include the cause when constructing RestoreSnapshotException in restoreSnapshot
[
https://issues.apache.org/jira/browse/HBASE-22157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810299#comment-16810299
]
Hudson commented on HBASE-22157:
Results for branch branch-2
[build #1796 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1796//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Include the cause when constructing RestoreSnapshotException in
> restoreSnapshot
> ---
>
> Key: HBASE-22157
> URL: https://issues.apache.org/jira/browse/HBASE-22157
> Project: HBase
> Issue Type: Sub-task
> Components: Admin
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-22157.patch
>
>
> When implementing HBASE-21718, a snapshot related UT fails because of the
> incorrect cause of RestoreSnapshotException. Finally I found that we just a
> create a RestoreSnapshotException without providing the cause in
> restoreSnapshot.
> We should fix this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22007) Add restoreSnapshot and cloneSnapshot with acl methods in AsyncAdmin
[
https://issues.apache.org/jira/browse/HBASE-22007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810284#comment-16810284
]
Hudson commented on HBASE-22007:
Results for branch branch-2.2
[build #153 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Add restoreSnapshot and cloneSnapshot with acl methods in AsyncAdmin
>
>
> Key: HBASE-22007
> URL: https://issues.apache.org/jira/browse/HBASE-22007
> Project: HBase
> Issue Type: Task
> Components: Admin, asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-22007-v1.patch, HBASE-22007-v1.patch,
> HBASE-22007.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22073) /rits.jsp throws an exception if no procedure
[
https://issues.apache.org/jira/browse/HBASE-22073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810283#comment-16810283
]
Hudson commented on HBASE-22073:
Results for branch branch-2.2
[build #153 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> /rits.jsp throws an exception if no procedure
> -
>
> Key: HBASE-22073
> URL: https://issues.apache.org/jira/browse/HBASE-22073
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.1.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22073.branch-2.1.patch, HBASE-22073.master.patch
>
>
> I got the following exception in our test environment:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.generated.master.rits_jsp._jspService(rits_jsp.java:101)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...
> {noformat}
> Because {{regionStateNode.getProcedure()}} returns {{null}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[
https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810286#comment-16810286
]
Hudson commented on HBASE-22152:
Results for branch branch-2.2
[build #153 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Create a jenkins file for yetus to processing GitHub PR
> ---
>
> Key: HBASE-22152
> URL: https://issues.apache.org/jira/browse/HBASE-22152
> Project: HBase
> Issue Type: Sub-task
> Components: build
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1,
> 1.2.12, 2.1.5
>
> Attachments: HBASE-22152-v1.patch, HBASE-22152.patch
>
>
> I think we can just copy the jenkinsfile from the hadoop project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22157) Include the cause when constructing RestoreSnapshotException in restoreSnapshot
[
https://issues.apache.org/jira/browse/HBASE-22157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810285#comment-16810285
]
Hudson commented on HBASE-22157:
Results for branch branch-2.2
[build #153 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Include the cause when constructing RestoreSnapshotException in
> restoreSnapshot
> ---
>
> Key: HBASE-22157
> URL: https://issues.apache.org/jira/browse/HBASE-22157
> Project: HBase
> Issue Type: Sub-task
> Components: Admin
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-22157.patch
>
>
> When implementing HBASE-21718, a snapshot related UT fails because of the
> incorrect cause of RestoreSnapshotException. Finally I found that we just a
> create a RestoreSnapshotException without providing the cause in
> restoreSnapshot.
> We should fix this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22133) Forward port HBASE-22073 "/rits.jsp throws an exception if no procedure" to branch-2.2+
[
https://issues.apache.org/jira/browse/HBASE-22133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810282#comment-16810282
]
Hudson commented on HBASE-22133:
Results for branch branch-2.2
[build #153 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/153//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Forward port HBASE-22073 "/rits.jsp throws an exception if no procedure" to
> branch-2.2+
> ---
>
> Key: HBASE-22133
> URL: https://issues.apache.org/jira/browse/HBASE-22133
> Project: HBase
> Issue Type: Bug
> Components: UI
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-22133-v1.patch, HBASE-22133.patch
>
>
> The RIT procedure has been changed for branch-2.2+ so we can not use the
> patch for branch-2.1 directly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[
https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810281#comment-16810281
]
Hudson commented on HBASE-22152:
Results for branch branch-1
[build #753 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/753/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/753//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/750//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/750//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Create a jenkins file for yetus to processing GitHub PR
> ---
>
> Key: HBASE-22152
> URL: https://issues.apache.org/jira/browse/HBASE-22152
> Project: HBase
> Issue Type: Sub-task
> Components: build
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1,
> 1.2.12, 2.1.5
>
> Attachments: HBASE-22152-v1.patch, HBASE-22152.patch
>
>
> I think we can just copy the jenkinsfile from the hadoop project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[
https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810280#comment-16810280
]
Hudson commented on HBASE-22152:
Results for branch master
[build #907 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/907/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/907//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/907//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/907//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Create a jenkins file for yetus to processing GitHub PR
> ---
>
> Key: HBASE-22152
> URL: https://issues.apache.org/jira/browse/HBASE-22152
> Project: HBase
> Issue Type: Sub-task
> Components: build
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1,
> 1.2.12, 2.1.5
>
> Attachments: HBASE-22152-v1.patch, HBASE-22152.patch
>
>
> I think we can just copy the jenkinsfile from the hadoop project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22114) Port HBASE-15560 (TinyLFU-based BlockCache) to branch-1
[
https://issues.apache.org/jira/browse/HBASE-22114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810261#comment-16810261
]
Andrew Purtell commented on HBASE-22114:
{quote}I'm concerned we'll break precommit on branch-1 for good though.
{quote}
Me too
> Port HBASE-15560 (TinyLFU-based BlockCache) to branch-1
> ---
>
> Key: HBASE-22114
> URL: https://issues.apache.org/jira/browse/HBASE-22114
> Project: HBase
> Issue Type: Sub-task
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 1.6.0
>
> Attachments: HBASE-22114-branch-1.patch, HBASE-22114-branch-1.patch,
> HBASE-22114-branch-1.patch
>
>
> HBASE-15560 introduces the TinyLFU cache policy for the blockcache.
> W-TinyLFU ([research paper|http://arxiv.org/pdf/1512.00727.pdf]) records the
> frequency in a counting sketch, ages periodically by halving the counters,
> and orders entries by SLRU. An entry is discarded by comparing the frequency
> of the new arrival (candidate) to the SLRU's victim, and keeping the one with
> the highest frequency. This allows the operations to be performed in O(1)
> time and, though the use of a compact sketch, a much larger history is
> retained beyond the current working set. In a variety of real world traces
> the policy had [near optimal hit
> rates|https://github.com/ben-manes/caffeine/wiki/Efficiency].
> The implementation of HBASE-15560 uses several Java 8 idioms, depends on JRE
> 8+ type Optional, and has dependencies on libraries compiled with Java 8+
> bytecode. It could be backported to branch-1 but must be made optional both
> at compile time and runtime, enabled by the 'build-with-jdk8' build profile.
> The TinyLFU policy must go into its own build module.
> The blockcache must be modified to load L1 implementation/policy dynamically
> at startup by reflection if the policy is "TinyLFU"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[ https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810258#comment-16810258 ] Hudson commented on HBASE-22152: SUCCESS: Integrated in Jenkins build HBase-1.2-IT #1216 (See [https://builds.apache.org/job/HBase-1.2-IT/1216/]) HBASE-22152 Create a jenkins file for yetus to processing GitHub PR (zhangduo: [https://github.com/apache/hbase/commit/f7819990cce74114f2f3686387adb02e56873134]) * (add) dev-support/Jenkinsfile_GitHub > Create a jenkins file for yetus to processing GitHub PR > --- > > Key: HBASE-22152 > URL: https://issues.apache.org/jira/browse/HBASE-22152 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1, > 1.2.12, 2.1.5 > > Attachments: HBASE-22152-v1.patch, HBASE-22152.patch > > > I think we can just copy the jenkinsfile from the hadoop project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[
https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810173#comment-16810173
]
Hudson commented on HBASE-22152:
Results for branch branch-1.3
[build #709 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/709/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/709//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/709//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/709//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Create a jenkins file for yetus to processing GitHub PR
> ---
>
> Key: HBASE-22152
> URL: https://issues.apache.org/jira/browse/HBASE-22152
> Project: HBase
> Issue Type: Sub-task
> Components: build
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1,
> 1.2.12, 2.1.5
>
> Attachments: HBASE-22152-v1.patch, HBASE-22152.patch
>
>
> I think we can just copy the jenkinsfile from the hadoop project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[
https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810162#comment-16810162
]
Hudson commented on HBASE-22152:
Results for branch branch-1.2
[build #720 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/720/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/720//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/720//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/720//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Create a jenkins file for yetus to processing GitHub PR
> ---
>
> Key: HBASE-22152
> URL: https://issues.apache.org/jira/browse/HBASE-22152
> Project: HBase
> Issue Type: Sub-task
> Components: build
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1,
> 1.2.12, 2.1.5
>
> Attachments: HBASE-22152-v1.patch, HBASE-22152.patch
>
>
> I think we can just copy the jenkinsfile from the hadoop project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22159) ByteBufferIOEngine should support write off-heap ByteBuff to the bufferArray
[
https://issues.apache.org/jira/browse/HBASE-22159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810143#comment-16810143
]
Hadoop QA commented on HBASE-22159:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
35s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-21879 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
34s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
32s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
20s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
28s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
40s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
7s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
49s{color} | {color:green} HBASE-21879 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
3s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
39s{color} | {color:red} hbase-common in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 39s{color}
| {color:red} hbase-common in the patch failed. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s{color} | {color:green} hbase-common: The patch generated 0 new + 0
unchanged - 6 fixed = 0 total (was 6) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
5s{color} | {color:green} The patch passed checkstyle in hbase-server {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
19s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 44s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
46s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
35s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}306m 10s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
54s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}357m 1s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.quotas.TestSpaceQuotas |
| | hadoop.hbase.master.procedure.TestTruncateTableProcedure |
| | hadoop.hbase.client.TestAsyncTableGetMultiThreaded |
| | hadoop.hbase.regionserver.TestSplitTransactionOnCluster |
| | hadoop.hbase.master.procedure.TestSCPWithReplicas |
| | hadoop.hbase.client.TestFromClientSideWithCoprocessor |
| |
hadoop.hbase.replication.multiwal.TestReplicationSyncUpToolWithMultipleAsyncWAL
|
| | hadoop.hbase.client.TestAsyncSnapshotAdminApi |
[jira] [Commented] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[
https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810142#comment-16810142
]
Hudson commented on HBASE-22152:
Results for branch branch-1.4
[build #729 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/729/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/729//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/729//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/729//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Create a jenkins file for yetus to processing GitHub PR
> ---
>
> Key: HBASE-22152
> URL: https://issues.apache.org/jira/browse/HBASE-22152
> Project: HBase
> Issue Type: Sub-task
> Components: build
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1,
> 1.2.12, 2.1.5
>
> Attachments: HBASE-22152-v1.patch, HBASE-22152.patch
>
>
> I think we can just copy the jenkinsfile from the hadoop project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22163) May send a warmup rpc for a splited parent region
[
https://issues.apache.org/jira/browse/HBASE-22163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810058#comment-16810058
]
Hadoop QA commented on HBASE-22163:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} 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
30s{color} | {color:blue} Maven dependency ordering for branch {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} 5m
0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
2s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
24s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
13s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
5s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 3m 35s{color}
| {color:red} hbase-server generated 1 new + 193 unchanged - 1 fixed = 194
total (was 194) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
28s{color} | {color:red} hbase-server: The patch generated 1 new + 568
unchanged - 0 fixed = 569 total (was 568) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
20s{color} | {color:green} The patch passed checkstyle in hbase-mapreduce
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
17s{color} | {color:green} hbase-examples: The patch generated 0 new + 2
unchanged - 1 fixed = 2 total (was 3) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
25s{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 20s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
14s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}321m 0s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 26m
54s{color} | {color:green} hbase-mapreduce in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
39s{color} | {color:green} hbase-examples in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
40s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}412m 4s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.tool.TestSecureLoadIncrementalHFiles |
| | hadoop.hbase.util.TestFromClientSide3WoUnsafe |
| | hadoop.hbase.cli
[jira] [Commented] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[ https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810034#comment-16810034 ] Hudson commented on HBASE-22152: SUCCESS: Integrated in Jenkins build HBase-1.3-IT #536 (See [https://builds.apache.org/job/HBase-1.3-IT/536/]) HBASE-22152 Create a jenkins file for yetus to processing GitHub PR (zhangduo: [https://github.com/apache/hbase/commit/b91284582c606210fd1f02935fe1e2ddc295981c]) * (add) dev-support/Jenkinsfile_GitHub > Create a jenkins file for yetus to processing GitHub PR > --- > > Key: HBASE-22152 > URL: https://issues.apache.org/jira/browse/HBASE-22152 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1, > 1.2.12, 2.1.5 > > Attachments: HBASE-22152-v1.patch, HBASE-22152.patch > > > I think we can just copy the jenkinsfile from the hadoop project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22164) Add a warn log when rs report failed open region
[
https://issues.apache.org/jira/browse/HBASE-22164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16810031#comment-16810031
]
Hadoop QA commented on HBASE-22164:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
21s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} 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} 5m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
25s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
39s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
32s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
11m 6s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
39s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}318m 53s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
24s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}370m 21s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.namespace.TestNamespaceAuditor |
| | hadoop.hbase.tool.TestSecureLoadIncrementalHFiles |
| | hadoop.hbase.util.TestFromClientSide3WoUnsafe |
| | hadoop.hbase.client.TestCloneSnapshotFromClientNormal |
| | hadoop.hbase.client.TestFromClientSide3 |
| | hadoop.hbase.client.TestAdmin1 |
| | hadoop.hbase.client.TestSnapshotDFSTemporaryDirectory |
| | hadoop.hbase.client.TestSnapshotTemporaryDirectoryWithRegionReplicas |
| | hadoop.hbase.client.TestFromClientSideWithCoprocessor |
| | hadoop.hbase.client.TestFromClientSide |
| | hadoop.hbase.client.TestAsyncTableAdminApi |
| | hadoop.hbase.replication.TestReplicationKillSlaveRSWithSeparateOldWALs |
| | hadoop.hbase.client.TestSnapshotTemporaryDirectory |
| | hadoop.hbase.tool.TestLoadIncrementalHFiles |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-22164 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964848/HBASE-22164.master.001.patch
|
| Optional Tes
[jira] [Commented] (HBASE-22156) Apply for translation of the Chinese version, I hope to get authorization!
[ https://issues.apache.org/jira/browse/HBASE-22156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809989#comment-16809989 ] Yuan Yifan commented on HBASE-22156: Hi, [~elserj] There're several points maybe I should declare: 1. We're a non-profit organization 2. We're changing our domain name and name recently because Apache worried about conflicting between the name "Apache" and "ApacheCN" 3. The reason of we got this name before is the admiration of open-source spirit of Apache 4. The QR code on the page is for donation, because we're a non-profit organization, we won't sale document or add advertisements on website for making money. 5. We're volunteers to translate these documents, so we translated these for free. But this does not mean that no funds are needed. We have to buy cloud servers, keep domain name and etc, so we need donations to maintain it. For the form of the cooperation between Apache and us, we suggest put a link on https://hbase.apache.org/ like the Chinese document which in 'Documentation and API'--but the document maybe a little expired and not user-friendly like ours. If there're any questions about us, please feel free to contact me or reply me in JIRA. Thank you for your support. > Apply for translation of the Chinese version, I hope to get authorization! > --- > > Key: HBASE-22156 > URL: https://issues.apache.org/jira/browse/HBASE-22156 > Project: HBase > Issue Type: Wish >Reporter: Yuan Yifan >Priority: Minor > > Hello everyone, we are [ApacheCN|https://www.apachecn.org/], an open-source > community in China, focusing on Big Data and AI. > Recently, we have been making progress on translating HBase documents. > - [Source Of Document|https://github.com/apachecn/hbase-doc-zh] > - [Document Preview|http://hbase.apachecn.org/] > There are several reasons: > *1. The English level of many Chinese users is not very good.* > *2. Network problems, you know (China's magic network)!* > *3. Online blogs are very messy.* > We are very willing to do some Chinese localization for your project. If > possible, please give us some authorization. > Yifan Yuan from Apache CN > You may contact me by mail [tsingjyuj...@163.com|mailto:tsingjyuj...@163.com] > for more details -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22143) HBCK2 setRegionState command
[
https://issues.apache.org/jira/browse/HBASE-22143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809986#comment-16809986
]
Wellington Chevreuil commented on HBASE-22143:
--
New patch attached:
1) Added message on the IllegalArgumentException check for RegionState.State
reference being null;
2) Changed return type to int, now method return EXIT_SUCCESS constant when it
runs smooth, EXIT_FAILURE otherwise;
3) Added check for info:state being null in meta;
4) Changed unit test to remove dependency on MetaTableAccessor
(Audience.Private);
> HBCK2 setRegionState command
>
>
> Key: HBASE-22143
> URL: https://issues.apache.org/jira/browse/HBASE-22143
> Project: HBase
> Issue Type: New Feature
> Components: hbase-operator-tools, hbck2
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Minor
> Attachments: HBASE-22143.master.0001.patch,
> HBASE-22143.master.0002.patch, HBASE-22143.master.0003.patch
>
>
> Among some of the current AMv2 issues, we faced situation where some regions
> had state as OPENING in meta, with an RS startcode that was not valid
> anymore. There was no AP running, the region stays permanently being logged
> as IN-Transition on master logs, yet no procedure is really trying to bring
> it online. Current hbck2 unassigns/assigns commands didn't work either, as
> per the exception shown, it expects regions to be in state SPLITTING, SPLIT,
> MERGING, OPEN, or CLOSING:
> {noformat}
> WARN org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure:
> Failed transition, suspend 1secs pid=7093,
> state=RUNNABLE:REGION_TRANSITION_DISPATCH, locked=true; UnassignProcedure
> table=rc_accounts, region=db85127b77fa56f7ad44e2c988e53925,
> server=server1.example.com,16020,1552682193324; rit=OPENING,
> location=server1.example.com,16020,1552682193324; waiting on rectified
> condition fixed by other Procedure or operator intervention
> org.apache.hadoop.hbase.exceptions.UnexpectedStateException: Expected
> [SPLITTING, SPLIT, MERGING, OPEN, CLOSING] so could move to CLOSING but
> current state=OPENING
> at
> org.apache.hadoop.hbase.master.assignment.RegionStates$RegionStateNode.transitionState(RegionStates.java:166)
> at
> org.apache.hadoop.hbase.master.assignment.AssignmentManager.markRegionAsClosing(AssignmentManager.java:1479)
> at
> org.apache.hadoop.hbase.master.assignment.UnassignProcedure.updateTransition(UnassignProcedure.java:212)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:369)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:97)
> at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:957)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1835)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1595){noformat}
> In this specific case, since we know the region is not actually being
> operated by any proc and is not really open anywhere, it's ok to manually set
> it's state to one of those assigns/unassigns can operate on, so this jira
> proposes a new hbck2 command that allows for arbitrarily set a region to a
> given state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22158) RawAsyncHBaseAdmin.getTableSplits should filter out none default replicas
[
https://issues.apache.org/jira/browse/HBASE-22158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809985#comment-16809985
]
Hadoop QA commented on HBASE-22158:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
27s{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} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
31s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
10s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
50s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
33s{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
4s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
7m 55s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
50s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
25s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}247m 0s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
41s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}300m 44s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.client.TestSnapshotTemporaryDirectoryWithRegionReplicas |
| | hadoop.hbase.client.TestFromClientSide |
| | hadoop.hbase.client.TestAdmin1 |
| | hadoop.hbase.client.TestFromClientSideWithCoprocessor |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-22158 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964850/HBASE-22158.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 5cd12cd0c70f 4.4.0-137-generic #163-Ubuntu SMP Mon Sep 24
13:14:43 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkin
[jira] [Updated] (HBASE-22143) HBCK2 setRegionState command
[
https://issues.apache.org/jira/browse/HBASE-22143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wellington Chevreuil updated HBASE-22143:
-
Attachment: HBASE-22143.master.0003.patch
> HBCK2 setRegionState command
>
>
> Key: HBASE-22143
> URL: https://issues.apache.org/jira/browse/HBASE-22143
> Project: HBase
> Issue Type: New Feature
> Components: hbase-operator-tools, hbck2
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Minor
> Attachments: HBASE-22143.master.0001.patch,
> HBASE-22143.master.0002.patch, HBASE-22143.master.0003.patch
>
>
> Among some of the current AMv2 issues, we faced situation where some regions
> had state as OPENING in meta, with an RS startcode that was not valid
> anymore. There was no AP running, the region stays permanently being logged
> as IN-Transition on master logs, yet no procedure is really trying to bring
> it online. Current hbck2 unassigns/assigns commands didn't work either, as
> per the exception shown, it expects regions to be in state SPLITTING, SPLIT,
> MERGING, OPEN, or CLOSING:
> {noformat}
> WARN org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure:
> Failed transition, suspend 1secs pid=7093,
> state=RUNNABLE:REGION_TRANSITION_DISPATCH, locked=true; UnassignProcedure
> table=rc_accounts, region=db85127b77fa56f7ad44e2c988e53925,
> server=server1.example.com,16020,1552682193324; rit=OPENING,
> location=server1.example.com,16020,1552682193324; waiting on rectified
> condition fixed by other Procedure or operator intervention
> org.apache.hadoop.hbase.exceptions.UnexpectedStateException: Expected
> [SPLITTING, SPLIT, MERGING, OPEN, CLOSING] so could move to CLOSING but
> current state=OPENING
> at
> org.apache.hadoop.hbase.master.assignment.RegionStates$RegionStateNode.transitionState(RegionStates.java:166)
> at
> org.apache.hadoop.hbase.master.assignment.AssignmentManager.markRegionAsClosing(AssignmentManager.java:1479)
> at
> org.apache.hadoop.hbase.master.assignment.UnassignProcedure.updateTransition(UnassignProcedure.java:212)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:369)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:97)
> at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:957)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1835)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1595){noformat}
> In this specific case, since we know the region is not actually being
> operated by any proc and is not really open anywhere, it's ok to manually set
> it's state to one of those assigns/unassigns can operate on, so this jira
> proposes a new hbck2 command that allows for arbitrarily set a region to a
> given state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22143) HBCK2 setRegionState command
[
https://issues.apache.org/jira/browse/HBASE-22143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809966#comment-16809966
]
Josh Elser commented on HBASE-22143:
{quote}I guess IllegalArgument would be more reasonable, no?
{quote}
I've seen it both ways. Dealer's choice, no firm feelings from me :)
{quote}I was following the pattern already used by *setTableState* method, but
actually don't see much value in return the previous state value, so maybe
better make this method void anyway. If the specified region is not found in
meta, it already prints an error message. May do same for the case of no state
info as well.
{quote}
Sounds good.
> HBCK2 setRegionState command
>
>
> Key: HBASE-22143
> URL: https://issues.apache.org/jira/browse/HBASE-22143
> Project: HBase
> Issue Type: New Feature
> Components: hbase-operator-tools, hbck2
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Minor
> Attachments: HBASE-22143.master.0001.patch,
> HBASE-22143.master.0002.patch
>
>
> Among some of the current AMv2 issues, we faced situation where some regions
> had state as OPENING in meta, with an RS startcode that was not valid
> anymore. There was no AP running, the region stays permanently being logged
> as IN-Transition on master logs, yet no procedure is really trying to bring
> it online. Current hbck2 unassigns/assigns commands didn't work either, as
> per the exception shown, it expects regions to be in state SPLITTING, SPLIT,
> MERGING, OPEN, or CLOSING:
> {noformat}
> WARN org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure:
> Failed transition, suspend 1secs pid=7093,
> state=RUNNABLE:REGION_TRANSITION_DISPATCH, locked=true; UnassignProcedure
> table=rc_accounts, region=db85127b77fa56f7ad44e2c988e53925,
> server=server1.example.com,16020,1552682193324; rit=OPENING,
> location=server1.example.com,16020,1552682193324; waiting on rectified
> condition fixed by other Procedure or operator intervention
> org.apache.hadoop.hbase.exceptions.UnexpectedStateException: Expected
> [SPLITTING, SPLIT, MERGING, OPEN, CLOSING] so could move to CLOSING but
> current state=OPENING
> at
> org.apache.hadoop.hbase.master.assignment.RegionStates$RegionStateNode.transitionState(RegionStates.java:166)
> at
> org.apache.hadoop.hbase.master.assignment.AssignmentManager.markRegionAsClosing(AssignmentManager.java:1479)
> at
> org.apache.hadoop.hbase.master.assignment.UnassignProcedure.updateTransition(UnassignProcedure.java:212)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:369)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:97)
> at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:957)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1835)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1595){noformat}
> In this specific case, since we know the region is not actually being
> operated by any proc and is not really open anywhere, it's ok to manually set
> it's state to one of those assigns/unassigns can operate on, so this jira
> proposes a new hbck2 command that allows for arbitrarily set a region to a
> given state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22114) Port HBASE-15560 (TinyLFU-based BlockCache) to branch-1
[
https://issues.apache.org/jira/browse/HBASE-22114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809965#comment-16809965
]
Sean Busbey commented on HBASE-22114:
-
{quote}
Also, it looks like javadoc was invoked on the tinylfu module under java 7 even
though that module is only ever conditionally defined and required from the
build-with-jdk8 profile, which has an activation predicate of jdk=1.8. Doesn't
happen when you build normally from the command line. I'm inclined to think
this is an issue with how Yetus decides what has changed and how Maven is
invoked to test those changes.
{quote}
yes it is. It detects that a module is present and expressly invokes maven to
build it, which we would tell folks not to do.
I think the patch looks good fundamentally. I'm concerned we'll break precommit
on branch-1 for good though.
Let me dedicate some time tomorrow to trying to untangle this.
> Port HBASE-15560 (TinyLFU-based BlockCache) to branch-1
> ---
>
> Key: HBASE-22114
> URL: https://issues.apache.org/jira/browse/HBASE-22114
> Project: HBase
> Issue Type: Sub-task
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 1.6.0
>
> Attachments: HBASE-22114-branch-1.patch, HBASE-22114-branch-1.patch,
> HBASE-22114-branch-1.patch
>
>
> HBASE-15560 introduces the TinyLFU cache policy for the blockcache.
> W-TinyLFU ([research paper|http://arxiv.org/pdf/1512.00727.pdf]) records the
> frequency in a counting sketch, ages periodically by halving the counters,
> and orders entries by SLRU. An entry is discarded by comparing the frequency
> of the new arrival (candidate) to the SLRU's victim, and keeping the one with
> the highest frequency. This allows the operations to be performed in O(1)
> time and, though the use of a compact sketch, a much larger history is
> retained beyond the current working set. In a variety of real world traces
> the policy had [near optimal hit
> rates|https://github.com/ben-manes/caffeine/wiki/Efficiency].
> The implementation of HBASE-15560 uses several Java 8 idioms, depends on JRE
> 8+ type Optional, and has dependencies on libraries compiled with Java 8+
> bytecode. It could be backported to branch-1 but must be made optional both
> at compile time and runtime, enabled by the 'build-with-jdk8' build profile.
> The TinyLFU policy must go into its own build module.
> The blockcache must be modified to load L1 implementation/policy dynamically
> at startup by reflection if the policy is "TinyLFU"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22163) May send a warmup rpc for a splited parent region
[
https://issues.apache.org/jira/browse/HBASE-22163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809948#comment-16809948
]
Hadoop QA commented on HBASE-22163:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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
23s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
2s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
6s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
13s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
37s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
12s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
48s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 3m 19s{color}
| {color:red} hbase-server generated 1 new + 193 unchanged - 1 fixed = 194
total (was 194) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
26s{color} | {color:red} hbase-server: The patch generated 1 new + 359
unchanged - 0 fixed = 360 total (was 359) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s{color} | {color:green} The patch passed checkstyle in hbase-mapreduce
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
16s{color} | {color:green} hbase-examples: The patch generated 0 new + 2
unchanged - 1 fixed = 2 total (was 3) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
24s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
11m 28s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
14s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}269m 17s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 25m
34s{color} | {color:green} hbase-mapreduce in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
25s{color} | {color:green} hbase-examples in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
14s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}358m 14s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.master.TestAssignmentManagerMetrics |
| | hadoop.hbase.client.TestAsyncTableRegionReplicasGet |
| | hadoop.hbas
[jira] [Commented] (HBASE-22147) Integrate the github pull request with hadoop QA.
[ https://issues.apache.org/jira/browse/HBASE-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809944#comment-16809944 ] Peter Somogyi commented on HBASE-22147: --- bq. I say just use private@hbase for now and if we run into an issue with github sending us an unacceptable amount of mail then we make a dedicated list. Fair enough! > Integrate the github pull request with hadoop QA. > - > > Key: HBASE-22147 > URL: https://issues.apache.org/jira/browse/HBASE-22147 > Project: HBase > Issue Type: Umbrella >Reporter: Zheng Hu >Assignee: Duo Zhang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22147) Integrate the github pull request with hadoop QA.
[ https://issues.apache.org/jira/browse/HBASE-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809937#comment-16809937 ] Sean Busbey commented on HBASE-22147: - is it possible to use the new jenkinsfile to drive tests of our jira based patches? at the moment that stuff lives only in the jenkins config. > Integrate the github pull request with hadoop QA. > - > > Key: HBASE-22147 > URL: https://issues.apache.org/jira/browse/HBASE-22147 > Project: HBase > Issue Type: Umbrella >Reporter: Zheng Hu >Assignee: Duo Zhang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22167) Unify the new github based pre commit job and our nightly job
[ https://issues.apache.org/jira/browse/HBASE-22167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809933#comment-16809933 ] Sean Busbey commented on HBASE-22167: - If we can do that while maintaining things as pipelines (so that we're still doing the various test parts in parallel when resources are available) then that'd be fine. I'm concerned though; that's an if block inside of a script block of a particular step of a particular stage. What you're talking about combining from nightly is a much larger set of stages. Is it worth this level of effort to avoid having 2 files? > Unify the new github based pre commit job and our nightly job > - > > Key: HBASE-22167 > URL: https://issues.apache.org/jira/browse/HBASE-22167 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Priority: Major > > Now we use two jenkins files and set up two jobs on jenkins. They both use > yetus and seems yetus 0.9.0 can have a PR tab and a branch tab in the same > job. So we can unify them together. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21512) Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
[
https://issues.apache.org/jira/browse/HBASE-21512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809927#comment-16809927
]
Hudson commented on HBASE-21512:
Results for branch HBASE-21512
[build #162 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/162/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/162//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/162//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/162//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
> --
>
> Key: HBASE-21512
> URL: https://issues.apache.org/jira/browse/HBASE-21512
> Project: HBase
> Issue Type: Umbrella
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
>
> At least for the RSProcedureDispatcher, with CompletableFuture we do not need
> to set a delay and use a thread pool any more, which could reduce the
> resource usage and also the latency.
> Once this is done, I think we can remove the ClusterConnection completely,
> and start to rewrite the old sync client based on the async client, which
> could reduce the code base a lot for our client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22147) Integrate the github pull request with hadoop QA.
[ https://issues.apache.org/jira/browse/HBASE-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809923#comment-16809923 ] Sean Busbey commented on HBASE-22147: - we haven't bothered to make a security@hbase list yet, and that seems like a place where we more regularly have work that could be done by committers instead of PMC members than maintenance of the github account. I say just use private@hbase for now and if we run into an issue with github sending us an unacceptable amount of mail then we make a dedicated list. > Integrate the github pull request with hadoop QA. > - > > Key: HBASE-22147 > URL: https://issues.apache.org/jira/browse/HBASE-22147 > Project: HBase > Issue Type: Umbrella >Reporter: Zheng Hu >Assignee: Duo Zhang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22143) HBCK2 setRegionState command
[
https://issues.apache.org/jira/browse/HBASE-22143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809922#comment-16809922
]
Wellington Chevreuil commented on HBASE-22143:
--
{quote}I think {{Enum.valueOf}} will automatically throw an
IllegalArgumentException for you. Could throw a NullPointerException here
instead to make that distinction. A message would be nice, too.
{quote}
Yeah, assuming caller will try to get an enum value from null, but it's also
possible caller can pass null to the enum reference. Agreed we should provide a
message. Since we can't really do anything without a State, I guess
IllegalArgument would be more reasonable, no?
{quote}This may return null. Need a check for that (in case meta is malformed).
{quote}
Well spotted, let me address that too.
{quote}This would result in us printing out a "null" to the stdout when we
can't find the region in meta which wouldn't make much sense. I'd suggest
either doing away with printing the return value from setRegionState or buff it
up with some more description
{quote}
I was following the pattern already used by *setTableState* method, but
actually don't see much value in return the previous state value, so maybe
better make this method void anyway. If the specified region is not found in
meta, it already prints an error message. May do same for the case of no state
info as well.
Will post an updated patch soon.
> HBCK2 setRegionState command
>
>
> Key: HBASE-22143
> URL: https://issues.apache.org/jira/browse/HBASE-22143
> Project: HBase
> Issue Type: New Feature
> Components: hbase-operator-tools, hbck2
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Minor
> Attachments: HBASE-22143.master.0001.patch,
> HBASE-22143.master.0002.patch
>
>
> Among some of the current AMv2 issues, we faced situation where some regions
> had state as OPENING in meta, with an RS startcode that was not valid
> anymore. There was no AP running, the region stays permanently being logged
> as IN-Transition on master logs, yet no procedure is really trying to bring
> it online. Current hbck2 unassigns/assigns commands didn't work either, as
> per the exception shown, it expects regions to be in state SPLITTING, SPLIT,
> MERGING, OPEN, or CLOSING:
> {noformat}
> WARN org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure:
> Failed transition, suspend 1secs pid=7093,
> state=RUNNABLE:REGION_TRANSITION_DISPATCH, locked=true; UnassignProcedure
> table=rc_accounts, region=db85127b77fa56f7ad44e2c988e53925,
> server=server1.example.com,16020,1552682193324; rit=OPENING,
> location=server1.example.com,16020,1552682193324; waiting on rectified
> condition fixed by other Procedure or operator intervention
> org.apache.hadoop.hbase.exceptions.UnexpectedStateException: Expected
> [SPLITTING, SPLIT, MERGING, OPEN, CLOSING] so could move to CLOSING but
> current state=OPENING
> at
> org.apache.hadoop.hbase.master.assignment.RegionStates$RegionStateNode.transitionState(RegionStates.java:166)
> at
> org.apache.hadoop.hbase.master.assignment.AssignmentManager.markRegionAsClosing(AssignmentManager.java:1479)
> at
> org.apache.hadoop.hbase.master.assignment.UnassignProcedure.updateTransition(UnassignProcedure.java:212)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:369)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:97)
> at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:957)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1835)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1595){noformat}
> In this specific case, since we know the region is not actually being
> operated by any proc and is not really open anywhere, it's ok to manually set
> it's state to one of those assigns/unassigns can operate on, so this jira
> proposes a new hbck2 command that allows for arbitrarily set a region to a
> given state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22147) Integrate the github pull request with hadoop QA.
[ https://issues.apache.org/jira/browse/HBASE-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809921#comment-16809921 ] Duo Zhang commented on HBASE-22147: --- On github we are talking about creating our own github account for posting comments on github, instead of using the hadoop-yetus. And the last thing is about which email address to use, private@hbase or a new hbase-yetus. [~elserj] [~busbey] [~psomogyi] Thanks. > Integrate the github pull request with hadoop QA. > - > > Key: HBASE-22147 > URL: https://issues.apache.org/jira/browse/HBASE-22147 > Project: HBase > Issue Type: Umbrella >Reporter: Zheng Hu >Assignee: Duo Zhang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase] Apache9 commented on issue #110: For testing github PR
Apache9 commented on issue #110: For testing github PR URL: https://github.com/apache/hbase/pull/110#issuecomment-479923647 Oh, I deleted the HBASE-22147 branch after committing HBASE-22152... Let continue the discussion on HBASE-22147. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22167) Unify the new github based pre commit job and our nightly job
[
https://issues.apache.org/jira/browse/HBASE-22167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809916#comment-16809916
]
Duo Zhang commented on HBASE-22167:
---
You can see the if here
https://github.com/apache/hbase/blob/master/dev-support/Jenkinsfile_GitHub#L104
{code}
if [[ -n "${JIRA_ISSUE_KEY}" ]]; then
YETUS_ARGS+=("${JIRA_ISSUE_KEY}")
elif [[ -z "${CHANGE_URL}" ]]; then
echo "Full build skipped" >
"${WORKSPACE}/${PATCHDIR}/report.html"
exit 0
fi
{code}
If we go into the last branch then we are running a nightly build. So I think
it is possible to unify them together, FWIW, we can copy paste all the scripts
in the old Jenkinsfile into the last condition branch...
> Unify the new github based pre commit job and our nightly job
> -
>
> Key: HBASE-22167
> URL: https://issues.apache.org/jira/browse/HBASE-22167
> Project: HBase
> Issue Type: Sub-task
>Reporter: Duo Zhang
>Priority: Major
>
> Now we use two jenkins files and set up two jobs on jenkins. They both use
> yetus and seems yetus 0.9.0 can have a PR tab and a branch tab in the same
> job. So we can unify them together.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[ https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-22152: -- Resolution: Fixed Release Note: Add a new jenkins file for running pre commit check for GitHub PR. Status: Resolved (was: Patch Available) Pushed to all active branches. > Create a jenkins file for yetus to processing GitHub PR > --- > > Key: HBASE-22152 > URL: https://issues.apache.org/jira/browse/HBASE-22152 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1, > 1.2.12, 2.1.5 > > Attachments: HBASE-22152-v1.patch, HBASE-22152.patch > > > I think we can just copy the jenkinsfile from the hadoop project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase] asfgit closed pull request #110: For testing github PR
asfgit closed pull request #110: For testing github PR URL: https://github.com/apache/hbase/pull/110 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [hbase] busbey commented on issue #110: For testing github PR
busbey commented on issue #110: For testing github PR URL: https://github.com/apache/hbase/pull/110#issuecomment-479920380 we could use private@hbase. I believe the apache-yetus account uses private@yetus. If I had to guess, I'd say making a new email list as hadoop-yetus did would be so that non-PMC members can share in maintenance work. If we want that, then yes I think an INFRA jira is needed since we'd want it to be private. (there's a self-serve thing for making public mailing lists.) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22167) Unify the new github based pre commit job and our nightly job
[ https://issues.apache.org/jira/browse/HBASE-22167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809899#comment-16809899 ] Sean Busbey commented on HBASE-22167: - I'm not sure we can unify them. We do a ton of testing in nightly that we needn't do on each new contribution. > Unify the new github based pre commit job and our nightly job > - > > Key: HBASE-22167 > URL: https://issues.apache.org/jira/browse/HBASE-22167 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Priority: Major > > Now we use two jenkins files and set up two jobs on jenkins. They both use > yetus and seems yetus 0.9.0 can have a PR tab and a branch tab in the same > job. So we can unify them together. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase] Apache9 commented on issue #110: For testing github PR
Apache9 commented on issue #110: For testing github PR URL: https://github.com/apache/hbase/pull/110#issuecomment-479914234 > If I'm correct the hadoop-yetus email address was created for this and made it private. We could do the same and request an hbase-yetus list for this purpose. So file an issue on infra? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [hbase] Apache9 commented on issue #110: For testing github PR
Apache9 commented on issue #110: For testing github PR URL: https://github.com/apache/hbase/pull/110#issuecomment-479914026 And another thing is that, seems the hadoop-yetus can only comment on this PR but for the PRs of hadoop, the hadoop-yetus can start a review. Maybe this also means we need to create our own account and do some magics... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22143) HBCK2 setRegionState command
[
https://issues.apache.org/jira/browse/HBASE-22143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809891#comment-16809891
]
Josh Elser commented on HBASE-22143:
{code:java}
+if(newState==null){
+ throw new IllegalArgumentException();
+}{code}
I think {{Enum.valueOf}} will automatically throw an IllegalArgumentException
for you. Could throw a NullPointerException here instead to make that
distinction. A message would be nice, too.
{code:java}
+byte[] currentStateValue = result.getValue(HConstants.CATALOG_FAMILY,
+ HConstants.STATE_QUALIFIER);
{code}
This may return null. Need a check for that (in case meta is malformed).
{code:java}
+return currentState;
...
+System.out.println(setRegionState(commands[1],
RegionState.State.valueOf(commands[2])));{code}
This would result in us printing out a "null" to the stdout when we can't find
the region in meta which wouldn't make much sense. I'd suggest either doing
away with printing the return value from {{setRegionState}} or buff it up with
some more description (e.g. {{"Result from setting state of " + commands[1] + "
was " + setRegionState(..)}} )
> HBCK2 setRegionState command
>
>
> Key: HBASE-22143
> URL: https://issues.apache.org/jira/browse/HBASE-22143
> Project: HBase
> Issue Type: New Feature
> Components: hbase-operator-tools, hbck2
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Minor
> Attachments: HBASE-22143.master.0001.patch,
> HBASE-22143.master.0002.patch
>
>
> Among some of the current AMv2 issues, we faced situation where some regions
> had state as OPENING in meta, with an RS startcode that was not valid
> anymore. There was no AP running, the region stays permanently being logged
> as IN-Transition on master logs, yet no procedure is really trying to bring
> it online. Current hbck2 unassigns/assigns commands didn't work either, as
> per the exception shown, it expects regions to be in state SPLITTING, SPLIT,
> MERGING, OPEN, or CLOSING:
> {noformat}
> WARN org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure:
> Failed transition, suspend 1secs pid=7093,
> state=RUNNABLE:REGION_TRANSITION_DISPATCH, locked=true; UnassignProcedure
> table=rc_accounts, region=db85127b77fa56f7ad44e2c988e53925,
> server=server1.example.com,16020,1552682193324; rit=OPENING,
> location=server1.example.com,16020,1552682193324; waiting on rectified
> condition fixed by other Procedure or operator intervention
> org.apache.hadoop.hbase.exceptions.UnexpectedStateException: Expected
> [SPLITTING, SPLIT, MERGING, OPEN, CLOSING] so could move to CLOSING but
> current state=OPENING
> at
> org.apache.hadoop.hbase.master.assignment.RegionStates$RegionStateNode.transitionState(RegionStates.java:166)
> at
> org.apache.hadoop.hbase.master.assignment.AssignmentManager.markRegionAsClosing(AssignmentManager.java:1479)
> at
> org.apache.hadoop.hbase.master.assignment.UnassignProcedure.updateTransition(UnassignProcedure.java:212)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:369)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:97)
> at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:957)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1835)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1595){noformat}
> In this specific case, since we know the region is not actually being
> operated by any proc and is not really open anywhere, it's ok to manually set
> it's state to one of those assigns/unassigns can operate on, so this jira
> proposes a new hbck2 command that allows for arbitrarily set a region to a
> given state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] petersomogyi commented on issue #110: For testing github PR
petersomogyi commented on issue #110: For testing github PR URL: https://github.com/apache/hbase/pull/110#issuecomment-479911199 If I'm correct the hadoop-yetus email address was created for this and made it private. We could do the same and request an hbase-yetus list for this purpose. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [hbase] joshelser commented on issue #110: For testing github PR
joshelser commented on issue #110: For testing github PR URL: https://github.com/apache/hbase/pull/110#issuecomment-479910598 > We need an email address when creating a github account, so just the private@hbase? That'd be my suggestion. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[
https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809887#comment-16809887
]
Hadoop QA commented on HBASE-22152:
---
| (/) *{color:green}+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:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
0s{color} | {color:blue} Shelldocs was not available. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
0s{color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
1s{color} | {color:green} The patch has no whitespace issues. {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 0m 47s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-22152 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964871/HBASE-22152-v1.patch |
| Optional Tests | dupname asflicense shellcheck shelldocs |
| uname | Linux 6010b44db6ec 4.4.0-131-generic #157~14.04.1-Ubuntu SMP Fri Jul
13 08:53:17 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 3e8152837e |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| shellcheck | v0.4.4 |
| Max. process+thread count | 43 (vs. ulimit of 1) |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/16654/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Create a jenkins file for yetus to processing GitHub PR
> ---
>
> Key: HBASE-22152
> URL: https://issues.apache.org/jira/browse/HBASE-22152
> Project: HBase
> Issue Type: Sub-task
> Components: build
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1,
> 1.2.12, 2.1.5
>
> Attachments: HBASE-22152-v1.patch, HBASE-22152.patch
>
>
> I think we can just copy the jenkinsfile from the hadoop project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] Apache9 commented on issue #110: For testing github PR
Apache9 commented on issue #110: For testing github PR URL: https://github.com/apache/hbase/pull/110#issuecomment-479910021 @joshelser We need an email address when creating a github account, so just the private@hbase? It seems that we also have an apache-yetus account, so how do the yetus PMC members manage this account? Out mighty @busbey , I think you are the PMC member of yetus. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[ https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-22152: -- Status: Patch Available (was: Open) > Create a jenkins file for yetus to processing GitHub PR > --- > > Key: HBASE-22152 > URL: https://issues.apache.org/jira/browse/HBASE-22152 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1, > 1.2.12, 2.1.5 > > Attachments: HBASE-22152-v1.patch, HBASE-22152.patch > > > I think we can just copy the jenkinsfile from the hadoop project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[ https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-22152: -- Attachment: HBASE-22152-v1.patch > Create a jenkins file for yetus to processing GitHub PR > --- > > Key: HBASE-22152 > URL: https://issues.apache.org/jira/browse/HBASE-22152 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1, > 1.2.12, 2.1.5 > > Attachments: HBASE-22152-v1.patch, HBASE-22152.patch > > > I think we can just copy the jenkinsfile from the hadoop project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22143) HBCK2 setRegionState command
[
https://issues.apache.org/jira/browse/HBASE-22143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809879#comment-16809879
]
Josh Elser commented on HBASE-22143:
{quote}After all, manually setting region states even to CLOSED is already too
risky, would require operators to really know what they are doing. What do you
think? If you still find worth lock the options, I can change that too,
{quote}
Sounds good. I think since we are "early on", giving flexibility is the right
answer. Hopefully, this is something that falls to the wayside – we would never
need more than assign/unassign because we never get into states where things
are orphaned :)
Let me take a look at your new patch.
> HBCK2 setRegionState command
>
>
> Key: HBASE-22143
> URL: https://issues.apache.org/jira/browse/HBASE-22143
> Project: HBase
> Issue Type: New Feature
> Components: hbase-operator-tools, hbck2
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Minor
> Attachments: HBASE-22143.master.0001.patch,
> HBASE-22143.master.0002.patch
>
>
> Among some of the current AMv2 issues, we faced situation where some regions
> had state as OPENING in meta, with an RS startcode that was not valid
> anymore. There was no AP running, the region stays permanently being logged
> as IN-Transition on master logs, yet no procedure is really trying to bring
> it online. Current hbck2 unassigns/assigns commands didn't work either, as
> per the exception shown, it expects regions to be in state SPLITTING, SPLIT,
> MERGING, OPEN, or CLOSING:
> {noformat}
> WARN org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure:
> Failed transition, suspend 1secs pid=7093,
> state=RUNNABLE:REGION_TRANSITION_DISPATCH, locked=true; UnassignProcedure
> table=rc_accounts, region=db85127b77fa56f7ad44e2c988e53925,
> server=server1.example.com,16020,1552682193324; rit=OPENING,
> location=server1.example.com,16020,1552682193324; waiting on rectified
> condition fixed by other Procedure or operator intervention
> org.apache.hadoop.hbase.exceptions.UnexpectedStateException: Expected
> [SPLITTING, SPLIT, MERGING, OPEN, CLOSING] so could move to CLOSING but
> current state=OPENING
> at
> org.apache.hadoop.hbase.master.assignment.RegionStates$RegionStateNode.transitionState(RegionStates.java:166)
> at
> org.apache.hadoop.hbase.master.assignment.AssignmentManager.markRegionAsClosing(AssignmentManager.java:1479)
> at
> org.apache.hadoop.hbase.master.assignment.UnassignProcedure.updateTransition(UnassignProcedure.java:212)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:369)
> at
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure.execute(RegionTransitionProcedure.java:97)
> at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:957)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1835)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1595){noformat}
> In this specific case, since we know the region is not actually being
> operated by any proc and is not really open anywhere, it's ok to manually set
> it's state to one of those assigns/unassigns can operate on, so this jira
> proposes a new hbck2 command that allows for arbitrarily set a region to a
> given state.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] joshelser commented on issue #110: For testing github PR
joshelser commented on issue #110: For testing github PR URL: https://github.com/apache/hbase/pull/110#issuecomment-479904928 > OK, the only problem is that how do we share the github account across the PMC members... Maybe just a randomly generated password sent to private@hbase for now? Don't want that to the be the thing holding you up :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [hbase] Apache9 commented on issue #110: For testing github PR
Apache9 commented on issue #110: For testing github PR URL: https://github.com/apache/hbase/pull/110#issuecomment-479903086 Oh, it is just the company field of the github profile, not the Organizations... OK, the only problem is that how do we share the github account across the PMC members... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22127) Ensure that the block cached in the LRUBlockCache offheap is allocated from heap
[
https://issues.apache.org/jira/browse/HBASE-22127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809869#comment-16809869
]
Hadoop QA commented on HBASE-22127:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 3m
52s{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 9 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-21879 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
30s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
9s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
21s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
29s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
28s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
10s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
45s{color} | {color:green} HBASE-21879 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
14s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 2m 38s{color}
| {color:red} hbase-server generated 1 new + 193 unchanged - 1 fixed = 194
total (was 194) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
20s{color} | {color:red} hbase-common: The patch generated 1 new + 0 unchanged
- 0 fixed = 1 total (was 0) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
2s{color} | {color:green} hbase-server: The patch generated 0 new + 137
unchanged - 4 fixed = 137 total (was 141) {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
26s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 51s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
14s{color} | {color:green} the patch passed {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:green}+1{color} | {color:green} unit {color} | {color:green} 2m
29s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}298m 2s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
39s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}349m 40s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.master.procedure.TestSCPWithReplicas |
| | hadoop.hbase.master.TestAssignmentManagerMetrics |
| | hadoop.hbase.master.procedure.TestSCPWithReplicasWithoutZKCoordinated |
| | hadoop.hbase.master.TestSplitWALManager |
| | hadoop.hbase.client.TestAsyncTableGetMultiThreaded |
| | hadoop.hbase.client.TestFromClientSideWithCoprocessor |
| |
hadoop.hbase.replication.multiwal.TestReplicationSyncU
[jira] [Commented] (HBASE-22073) /rits.jsp throws an exception if no procedure
[
https://issues.apache.org/jira/browse/HBASE-22073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809862#comment-16809862
]
Hudson commented on HBASE-22073:
Results for branch master
[build #906 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/906/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/906//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/906//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/906//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> /rits.jsp throws an exception if no procedure
> -
>
> Key: HBASE-22073
> URL: https://issues.apache.org/jira/browse/HBASE-22073
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.1.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22073.branch-2.1.patch, HBASE-22073.master.patch
>
>
> I got the following exception in our test environment:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.generated.master.rits_jsp._jspService(rits_jsp.java:101)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...
> {noformat}
> Because {{regionStateNode.getProcedure()}} returns {{null}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22133) Forward port HBASE-22073 "/rits.jsp throws an exception if no procedure" to branch-2.2+
[
https://issues.apache.org/jira/browse/HBASE-22133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809861#comment-16809861
]
Hudson commented on HBASE-22133:
Results for branch master
[build #906 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/906/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/906//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/906//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/906//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Forward port HBASE-22073 "/rits.jsp throws an exception if no procedure" to
> branch-2.2+
> ---
>
> Key: HBASE-22133
> URL: https://issues.apache.org/jira/browse/HBASE-22133
> Project: HBase
> Issue Type: Bug
> Components: UI
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-22133-v1.patch, HBASE-22133.patch
>
>
> The RIT procedure has been changed for branch-2.2+ so we can not use the
> patch for branch-2.1 directly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22157) Include the cause when constructing RestoreSnapshotException in restoreSnapshot
[
https://issues.apache.org/jira/browse/HBASE-22157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809863#comment-16809863
]
Hudson commented on HBASE-22157:
Results for branch master
[build #906 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/906/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/906//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/906//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/906//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Include the cause when constructing RestoreSnapshotException in
> restoreSnapshot
> ---
>
> Key: HBASE-22157
> URL: https://issues.apache.org/jira/browse/HBASE-22157
> Project: HBase
> Issue Type: Sub-task
> Components: Admin
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-22157.patch
>
>
> When implementing HBASE-21718, a snapshot related UT fails because of the
> incorrect cause of RestoreSnapshotException. Finally I found that we just a
> create a RestoreSnapshotException without providing the cause in
> restoreSnapshot.
> We should fix this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21879) Read HFile's block to ByteBuffer directly instead of to byte for reducing young gc purpose
[
https://issues.apache.org/jira/browse/HBASE-21879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809860#comment-16809860
]
Hudson commented on HBASE-21879:
Results for branch HBASE-21879
[build #50 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/50/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/50//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/50//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/50//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Read HFile's block to ByteBuffer directly instead of to byte for reducing
> young gc purpose
> --
>
> Key: HBASE-21879
> URL: https://issues.apache.org/jira/browse/HBASE-21879
> Project: HBase
> Issue Type: Improvement
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-21879.v1.patch, HBASE-21879.v1.patch,
> QPS-latencies-before-HBASE-21879.png, gc-data-before-HBASE-21879.png
>
>
> In HFileBlock#readBlockDataInternal, we have the following:
> {code}
> @VisibleForTesting
> protected HFileBlock readBlockDataInternal(FSDataInputStream is, long offset,
> long onDiskSizeWithHeaderL, boolean pread, boolean verifyChecksum,
> boolean updateMetrics)
> throws IOException {
> // .
> // TODO: Make this ByteBuffer-based. Will make it easier to go to HDFS with
> BBPool (offheap).
> byte [] onDiskBlock = new byte[onDiskSizeWithHeader + hdrSize];
> int nextBlockOnDiskSize = readAtOffset(is, onDiskBlock, preReadHeaderSize,
> onDiskSizeWithHeader - preReadHeaderSize, true, offset +
> preReadHeaderSize, pread);
> if (headerBuf != null) {
> // ...
> }
> // ...
> }
> {code}
> In the read path, we still read the block from hfile to on-heap byte[], then
> copy the on-heap byte[] to offheap bucket cache asynchronously, and in my
> 100% get performance test, I also observed some frequent young gc, The
> largest memory footprint in the young gen should be the on-heap block byte[].
> In fact, we can read HFile's block to ByteBuffer directly instead of to
> byte[] for reducing young gc purpose. we did not implement this before,
> because no ByteBuffer reading interface in the older HDFS client, but 2.7+
> has supported this now, so we can fix this now. I think.
> Will provide an patch and some perf-comparison for this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] Apache9 commented on issue #110: For testing github PR
Apache9 commented on issue #110: For testing github PR URL: https://github.com/apache/hbase/pull/110#issuecomment-479897195 The token can be added by ourselves I believe, there is an 'Add' button after the Credentials config. And hadoop-yetus account is a member of the Apache on GitHub, I'm not sure how can we do this without the help of infra team? And we need to share a common email account across all the PMC members? Not sure what is the best practice... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (HBASE-22167) Unify the new github based pre commit job and our nightly job
Duo Zhang created HBASE-22167: - Summary: Unify the new github based pre commit job and our nightly job Key: HBASE-22167 URL: https://issues.apache.org/jira/browse/HBASE-22167 Project: HBase Issue Type: Sub-task Reporter: Duo Zhang Now we use two jenkins files and set up two jobs on jenkins. They both use yetus and seems yetus 0.9.0 can have a PR tab and a branch tab in the same job. So we can unify them together. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase] busbey commented on issue #110: For testing github PR
busbey commented on issue #110: For testing github PR URL: https://github.com/apache/hbase/pull/110#issuecomment-479894587 IIRC Steve L over in Hadoop set things up. Essentially he made the GitHub account and made sure the Hadoop pmc had control of it. I'm not sure if getting the access token into Jenkins was handled by himself or done via infra. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[ https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809847#comment-16809847 ] Duo Zhang commented on HBASE-22152: --- Seems perfect. https://github.com/apache/hbase/pull/110 Let me commit to all active branches. > Create a jenkins file for yetus to processing GitHub PR > --- > > Key: HBASE-22152 > URL: https://issues.apache.org/jira/browse/HBASE-22152 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1, > 1.2.12, 2.1.5 > > Attachments: HBASE-22152.patch > > > I think we can just copy the jenkinsfile from the hadoop project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22152) Create a jenkins file for yetus to processing GitHub PR
[ https://issues.apache.org/jira/browse/HBASE-22152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-22152: -- Fix Version/s: 2.1.5 1.2.12 1.5.1 2.0.6 2.3.0 1.3.4 1.4.10 2.2.0 3.0.0 > Create a jenkins file for yetus to processing GitHub PR > --- > > Key: HBASE-22152 > URL: https://issues.apache.org/jira/browse/HBASE-22152 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6, 1.5.1, > 1.2.12, 2.1.5 > > Attachments: HBASE-22152.patch > > > I think we can just copy the jenkinsfile from the hadoop project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22128) Move namespace region then master crashed make deadlock
[
https://issues.apache.org/jira/browse/HBASE-22128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809840#comment-16809840
]
Hadoop QA commented on HBASE-22128:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
20s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} branch-2.1 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
2s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
33s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
4s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
43s{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
2s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} branch-2.1 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
49s{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
24s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 26s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}214m
41s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
23s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}253m 40s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:42ca976 |
| JIRA Issue | HBASE-22128 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964836/HBASE-22128-branch-2.1-v5.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 111a8d8e5e0d 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24
10:58:50 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | branch-2.1 / 046984b961 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.11 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/16649/testReport/ |
| Max. process+thread count | 5022 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/16649/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automat
[jira] [Commented] (HBASE-22086) space quota issue: deleting snapshot doesn't update the usage of table
[
https://issues.apache.org/jira/browse/HBASE-22086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809839#comment-16809839
]
Hadoop QA commented on HBASE-22086:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} 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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
23s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
59s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
50s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
10s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
52s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
46s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 2m 49s{color}
| {color:red} hbase-server generated 1 new + 193 unchanged - 1 fixed = 194
total (was 194) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
30s{color} | {color:red} hbase-client: The patch generated 1 new + 2 unchanged
- 0 fixed = 3 total (was 2) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
16s{color} | {color:red} hbase-server: The patch generated 20 new + 1 unchanged
- 0 fixed = 21 total (was 1) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
14s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 22s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
57s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
32s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}321m 25s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
38s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}373m 52s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestSnapshotTemporaryDirectory |
| | hadoop.hbase.client.TestAsyncTableAdminApi |
| | hadoop.hbase.tool.TestSecureLoadIncrementalHFiles |
| | hadoop.hbase.namespace.TestNamespaceAuditor |
| | hadoop.hbase.client.TestFromClientSide3 |
| | hadoop.hbase.client.TestSnapshotTemporaryDirectoryWithRegionReplicas |
| | hadoop.hbase.replication.TestReplicationKillSlaveRSWithSeparateOldWALs |
| | hadoop.hbase.replication.TestReplic
[jira] [Commented] (HBASE-22147) Integrate the github pull request with hadoop QA.
[ https://issues.apache.org/jira/browse/HBASE-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809833#comment-16809833 ] Peter Somogyi commented on HBASE-22147: --- My bad, I was confused about the name of the personality file in the report output and it is indeed the hbase-personality. > Integrate the github pull request with hadoop QA. > - > > Key: HBASE-22147 > URL: https://issues.apache.org/jira/browse/HBASE-22147 > Project: HBase > Issue Type: Umbrella >Reporter: Zheng Hu >Assignee: Duo Zhang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22166) Space Quota issue: Namespace Quota policy is not getting imposed on the table in NS,when table level quota is set on the table and is violated and removed
[ https://issues.apache.org/jira/browse/HBASE-22166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uma Maheswari updated HBASE-22166: -- Affects Version/s: 3.0.0 2.0.0 > Space Quota issue: Namespace Quota policy is not getting imposed on the table > in NS,when table level quota is set on the table and is violated and removed > -- > > Key: HBASE-22166 > URL: https://issues.apache.org/jira/browse/HBASE-22166 > Project: HBase > Issue Type: Bug >Affects Versions: 3.0.0, 2.0.0 >Reporter: Uma Maheswari >Assignee: Uma Maheswari >Priority: Minor > > Space Quota issue: Namespace Quota policy is not getting imposed on the table > in NS,when table level quota is set on the table and is violated and removed > PFB the steps. > * create a NS and Set Quota > * create table under the NS and set Quota and write data to violate it > * Write data in NS and violate it > * Now remove the Quota in table level > Expected result: > * table should be moved to violation policy at NS level > Actual Result: > * NS level violation is shown in UI for the table > * in hbase:quota table no enry is present for that table > * violation policy is not imposed on the table > * insertion is allowed on the table which quota is removed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22147) Integrate the github pull request with hadoop QA.
[ https://issues.apache.org/jira/browse/HBASE-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809830#comment-16809830 ] Duo Zhang commented on HBASE-22147: --- [~psomogyi] What is the url you looked into? https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/view/change-requests/job/PR-110/2/artifact/out/precommit/personality/provided.sh/*view*/ It is the one in our repo I believe. > Integrate the github pull request with hadoop QA. > - > > Key: HBASE-22147 > URL: https://issues.apache.org/jira/browse/HBASE-22147 > Project: HBase > Issue Type: Umbrella >Reporter: Zheng Hu >Assignee: Duo Zhang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22166) Space Quota issue: Namespace Quota policy is not getting imposed on the table in NS,when table level quota is set on the table and is violated and removed
Uma Maheswari created HBASE-22166: - Summary: Space Quota issue: Namespace Quota policy is not getting imposed on the table in NS,when table level quota is set on the table and is violated and removed Key: HBASE-22166 URL: https://issues.apache.org/jira/browse/HBASE-22166 Project: HBase Issue Type: Bug Reporter: Uma Maheswari Assignee: Uma Maheswari Space Quota issue: Namespace Quota policy is not getting imposed on the table in NS,when table level quota is set on the table and is violated and removed PFB the steps. * create a NS and Set Quota * create table under the NS and set Quota and write data to violate it * Write data in NS and violate it * Now remove the Quota in table level Expected result: * table should be moved to violation policy at NS level Actual Result: * NS level violation is shown in UI for the table * in hbase:quota table no enry is present for that table * violation policy is not imposed on the table * insertion is allowed on the table which quota is removed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase] Apache9 commented on issue #110: For testing github PR
Apache9 commented on issue #110: For testing github PR URL: https://github.com/apache/hbase/pull/110#issuecomment-479888338 @busbey You can see the config of this job https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/ On the Credentials, you can select the hadoop-yetus. So we need to file an INFRA issue to create a new hbase-yetus github account? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (HBASE-22128) Move namespace region then master crashed make deadlock
[ https://issues.apache.org/jira/browse/HBASE-22128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bing Xiao updated HBASE-22128: -- Attachment: (was: HBASE-22128-branch-2.1-v5.patch) > Move namespace region then master crashed make deadlock > --- > > Key: HBASE-22128 > URL: https://issues.apache.org/jira/browse/HBASE-22128 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.5, 2.1.4 >Reporter: Bing Xiao >Assignee: Bing Xiao >Priority: Critical > Fix For: 2.0.6, 2.1.5 > > Attachments: HBASE-22128-branch-2.1-v1.patch, > HBASE-22128-branch-2.1-v2.patch, HBASE-22128-branch-2.1-v3.patch, > HBASE-22128-branch-2.1-v4.patch, HBASE-22128-branch-2.1-v5.patch > > > When move namespace region start unassign produre, after unassign procedure > finished namespace region will be offline. At the same time master crashed > then reboot will stuck, because master init is block by waiting namespace > table online ,at same time master init not finish so move region procedure > can not go on, make deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
