[jira] [Updated] (HBASE-19913) Split TestStochasticLoadBalancer2
[ https://issues.apache.org/jira/browse/HBASE-19913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19913: -- Attachment: HBASE-19913.patch > Split TestStochasticLoadBalancer2 > - > > Key: HBASE-19913 > URL: https://issues.apache.org/jira/browse/HBASE-19913 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19913.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19913) Split TestStochasticLoadBalancer2
[ https://issues.apache.org/jira/browse/HBASE-19913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19913: -- Status: Patch Available (was: Open) > Split TestStochasticLoadBalancer2 > - > > Key: HBASE-19913 > URL: https://issues.apache.org/jira/browse/HBASE-19913 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19913.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-19913) Split TestStochasticLoadBalancer2
Duo Zhang created HBASE-19913: - Summary: Split TestStochasticLoadBalancer2 Key: HBASE-19913 URL: https://issues.apache.org/jira/browse/HBASE-19913 Project: HBase Issue Type: Sub-task Components: test Reporter: Duo Zhang Assignee: Duo Zhang Fix For: 2.0.0-beta-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19876) The exception happening in converting pb mutation to hbase.mutation messes up the CellScanner
[
https://issues.apache.org/jira/browse/HBASE-19876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348143#comment-16348143
]
Hadoop QA commented on HBASE-19876:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
15s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
58s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
54s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
43s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
8s{color} | {color:red} hbase-server: The patch generated 2 new + 130 unchanged
- 0 fixed = 132 total (was 130) {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
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}
21m 15s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
58s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 38m 45s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
27s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 80m 23s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.TestClientClusterMetrics |
| | hadoop.hbase.favored.TestFavoredNodeAssignmentHelper |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19876 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12908728/HBASE-19876.v1.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux e3eea62c867b 3.13.0-135-generic #184-Ubuntu SMP Wed Oct 18
11:55:51 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 9272f40a5c |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/11316/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/11316/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/11316/testReport/ |
| Max.
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348142#comment-16348142 ] Duo Zhang commented on HBASE-19904: --- [~stack] Seems we still can not start mini cluster... > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v3.patch, HBASE-19904-v3.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19824) SingleColumnValueFilter returns wrong result when used in shell command
[
https://issues.apache.org/jira/browse/HBASE-19824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reid Chan updated HBASE-19824:
--
Attachment: HBASE-19824.master.002.patch
> SingleColumnValueFilter returns wrong result when used in shell command
> ---
>
> Key: HBASE-19824
> URL: https://issues.apache.org/jira/browse/HBASE-19824
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0-alpha-4
>Reporter: Ted Yu
>Assignee: Reid Chan
>Priority: Major
> Attachments: HBASE-19824.master.001.patch,
> HBASE-19824.master.002.patch
>
>
> There are two cells in table t1:
> {code}
> ROW COLUMN+CELL
> r1 column=f1:a1,
> timestamp=1516313683984, value=a2
> r1 column=f1:b1,
> timestamp=1516313700744, value=b2
> {code}
> When SingleColumnValueFilter is used in shell command, no filtering was done:
> {code}
> hbase(main):022:0> scan 't1', {FILTER => "SingleColumnValueFilter('f1', 'a1',
> =, 'binary:a2')"}
> ROW COLUMN+CELL
> r1 column=f1:a1,
> timestamp=1516313683984, value=a2
> r1 column=f1:b1,
> timestamp=1516313700744, value=b2
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348117#comment-16348117 ] Duo Zhang commented on HBASE-19904: --- Yes, the third step will be executed in replication.initialize. > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v3.patch, HBASE-19904-v3.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348114#comment-16348114 ] Guanghao Zhang commented on HBASE-19904: Read the patch, so the initializing sequence is: # new WALProvider # new replication and initial replication # Add replication as a WAL listener to WALProvider # get WAL from WALProvider Right? > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v3.patch, HBASE-19904-v3.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19703) Functionality added as part of HBASE-12583 is not working after moving the split code to master
[
https://issues.apache.org/jira/browse/HBASE-19703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348113#comment-16348113
]
Anoop Sam John commented on HBASE-19703:
ok. So this is used in HM side also.. Ok pls add some fat comments in
skipStoreFileRangeCheck that Region should not be referred here. This is been
used in HM side also. So later when some one adding new code in this method,
they will get the warn.
> Functionality added as part of HBASE-12583 is not working after moving the
> split code to master
> ---
>
> Key: HBASE-19703
> URL: https://issues.apache.org/jira/browse/HBASE-19703
> Project: HBase
> Issue Type: Bug
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19703-WIP.patch, HBASE-19703_v2.patch,
> HBASE-19703_v3.patch, HBASE-19703_v4.patch, HBASE-19703_v5.patch
>
>
> As part of HBASE-12583 we are passing split policy to
> HRegionFileSystem#splitStoreFile so that we can allow to create reference
> files even the split key is out of HFile key range. This is needed for Local
> Indexing implementation in Phoenix. But now after moving the split code to
> master just passing null for split policy.
> {noformat}
> final String familyName = Bytes.toString(family);
> final Path path_first =
> regionFs.splitStoreFile(this.daughter_1_RI, familyName, sf, splitRow,
> false, null);
> final Path path_second =
> regionFs.splitStoreFile(this.daughter_2_RI, familyName, sf, splitRow,
> true, null);
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19904: -- Attachment: HBASE-19904-v3.patch > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v3.patch, HBASE-19904-v3.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19908) TestCoprocessorShortCircuitRPC Timeout....
[ https://issues.apache.org/jira/browse/HBASE-19908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348093#comment-16348093 ] stack commented on HBASE-19908: --- bq. Yes, only up small to 60s without changing others. I'll do it on the next small test timeout > TestCoprocessorShortCircuitRPC Timeout > -- > > Key: HBASE-19908 > URL: https://issues.apache.org/jira/browse/HBASE-19908 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Priority: Major > Attachments: HBASE-19908.master.001.patch > > > Timedout in HBASE-19906 > Comparing a local run (16seconds total) to a timed out run up on jenkins, I > see it takes my local test 5 seconds to get the STOPPED server log line. On > jenkins in this timed out test it takes 30 seconds. Test is still running > when it is killed. Let me make it a medium test. > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/lastCompletedBuild/testReport/org.apache.hadoop.hbase.coprocessor/TestCoprocessorShortCircuitRPC/org_apache_hadoop_hbase_coprocessor_TestCoprocessorShortCircuitRPC/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348090#comment-16348090 ] stack commented on HBASE-19904: --- The netty test should be fixed. Others are MR? Saw this Thread 448 (Time-limited test-EventThread): State: BLOCKED Blocked count: 7 Waited count: 5 Blocked on org.apache.log4j.spi.RootLogger@79e37681 Blocked by 410 (Time-limited test-EventThread) Stack: org.apache.log4j.Category.callAppenders(Category.java:205) org.apache.log4j.Category.forcedLog(Category.java:391) org.apache.log4j.Category.log(Category.java:856) org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:576) org.slf4j.helpers.MarkerIgnoringBase.error(MarkerIgnoringBase.java:159) org.apache.hadoop.hbase.regionserver.HRegionServer.abort(HRegionServer.java:2338) org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.abortRegionServer(MiniHBaseCluster.java:208) org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.access$200(MiniHBaseCluster.java:133) org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer$2.run(MiniHBaseCluster.java:201) java.security.AccessController.doPrivileged(Native Method) javax.security.auth.Subject.doAs(Subject.java:360) org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1726) org.apache.hadoop.hbase.security.User$SecureHadoopUser.runAs(User.java:307) org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.abort(MiniHBaseCluster.java:198) org.apache.hadoop.hbase.zookeeper.ZKWatcher.connectionEvent(ZKWatcher.java:520) org.apache.hadoop.hbase.zookeeper.ZKWatcher.process(ZKWatcher.java:452) org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530) org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505) Inactive Didn't see the usual blocked on HMaster Will look again in morning. > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v3.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19902) Current Jenkins Madness: OOME, can't start minihbasecluster, etc.
[
https://issues.apache.org/jira/browse/HBASE-19902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348081#comment-16348081
]
stack commented on HBASE-19902:
---
[~aw] let me try it boss In the our qa job, in the Configuration, I added
in your suggestion. Seems like default is 4G looking over in yetus. It was not
set before. I added it in and I see it showing up here:
https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11314/console
Hopefully it takes effect. I'll let this run complete. Its proclimit 10k and
20g for docker.
This run is 20g for docker and 6k proclimit:
https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11317/console
Will see how they do.
Thanks for help.
> Current Jenkins Madness: OOME, can't start minihbasecluster, etc.
> -
>
> Key: HBASE-19902
> URL: https://issues.apache.org/jira/browse/HBASE-19902
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
>Priority: Major
> Attachments: HBASE-19902.temporary-2.001.patch
>
>
> Trying to figure what is going on w/ jenkins build
> Changed the hadoopqa config to output long process listing rather than just
> 'java'...
> I can't get loadavg... tried dumping /proc...
> /tmp/jenkins6485196190911961762.sh: line 48: /loadavg: Permission denied
> Looking at https://builds.apache.org/job/PreCommit-HBASE-Build/11273/console,
> see 7 java processes running on H2. Extra args on ps may help here whether it
> zombies of us.
> Test run was find then fell into hbase-server second part and soon after
> started failing..
> https://builds.apache.org/job/PreCommit-HBASE-Build/11273/artifact/patchprocess/patch-unit-hbase-server.txt
> Looking at first test failure... this is where main thread is, trying to get
> thread info:
> {code}
> Thread 23 (Time-limited test):
> State: RUNNABLE
> Blocked count: 118
> Waited count: 58
> Stack:
> sun.management.ThreadImpl.getThreadInfo1(Native Method)
> sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:178)
> sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:139)
>
> org.apache.hadoop.util.ReflectionUtils.printThreadInfo(ReflectionUtils.java:168)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:498)
>
> org.apache.hadoop.hbase.util.Threads$PrintThreadInfoLazyHolder$1.printThreadInfo(Threads.java:294)
> org.apache.hadoop.hbase.util.Threads.printThreadInfo(Threads.java:341)
>
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:191)
>
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:391)
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:262)
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:119)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1025)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:971)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:842)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:824)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:806)
>
> org.apache.hadoop.hbase.AcidGuaranteesTestBase.setUpBeforeClass(AcidGuaranteesTestBase.java:61)
> {code}
> Master is not coming up
> {code}
> 2018-01-31 02:22:31,474 ERROR [Time-limited test]
> hbase.MiniHBaseCluster(267): Error starting cluster
> java.lang.RuntimeException: Master not active after 3ms
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:192)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:391)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:262)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:119)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1025)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:971)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:842)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:824)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:806)
> at
>
[jira] [Commented] (HBASE-19906) TestZooKeeper Timeout
[ https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348075#comment-16348075 ] stack commented on HBASE-19906: --- .004 includes converting TestQoSFunction from Small to Medium Test. It timedout. Not a clean signal since the test makes little to no logs. For this test run, yetus is back to proclimit of 6000 but memory for the docker container is up to 20G from default of 4G. > TestZooKeeper Timeout > - > > Key: HBASE-19906 > URL: https://issues.apache.org/jira/browse/HBASE-19906 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19906.branch-2.001.patch, > HBASE-19906.branch-2.002.patch, HBASE-19906.branch-2.003.patch, > HBASE-19906.branch-2.003.patch, HBASE-19906.branch-2.004.patch, > HBASE-19906.branch-2.005.patch > > > TestZooKeeper is timing out causing hbase2 failures and breaking > HBASE-Flaky-Tests-branch2.0.0. > --- > Test set: org.apache.hadoop.hbase.TestZooKeeper > --- > Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 600.8 s <<< > FAILURE! - in org.apache.hadoop.hbase.TestZooKeeper > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.041 s <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 600 > seconds > at org.apache.hadoop.hbase.TestZooKeeper.after(TestZooKeeper.java:103) > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.046 s <<< ERROR! > java.lang.Exception: Appears to be stuck in thread > NIOServerCxn.Factory:0.0.0.0/0.0.0.0:59935 > Not always though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19911) Convert some tests from small to medium because they are timing out: TestNettyRpcServer, TestClientClusterStatus, TestCheckTestClasses
[ https://issues.apache.org/jira/browse/HBASE-19911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348073#comment-16348073 ] Chia-Ping Tsai commented on HBASE-19911: +1 > Convert some tests from small to medium because they are timing out: > TestNettyRpcServer, TestClientClusterStatus, TestCheckTestClasses > -- > > Key: HBASE-19911 > URL: https://issues.apache.org/jira/browse/HBASE-19911 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19911.branch-2.001.patch > > > Found some more timeouts of small tests. > TestNettyRpcServer > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11307/testReport/junit/org.apache.hadoop.hbase.ipc/TestNettyRpcServer/org_apache_hadoop_hbase_ipc_TestNettyRpcServer/ > On local machine takes 14 seconds to run 1 test. In the above failure..., the > test needs another second or so to complete It has been running 30 > seconds. > Starts a minihbasecluster, creates a table, then shuts down. Shouldn't even > take 3 seconds but thats another story. > TestClientClusterStatus is a small test that starts 5 regionservers and 3 > masters. Then does some stopping of servers, etc. > .. in same test run... > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11307/testReport/junit/org.apache.hadoop.hbase/TestClientClusterStatus/org_apache_hadoop_hbase_TestClientClusterStatus/ > ... it timed out after 30 seconds. Its almost done w/ shutdown but not quite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19906) TestZooKeeper Timeout
[ https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19906: -- Attachment: HBASE-19906.branch-2.005.patch > TestZooKeeper Timeout > - > > Key: HBASE-19906 > URL: https://issues.apache.org/jira/browse/HBASE-19906 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19906.branch-2.001.patch, > HBASE-19906.branch-2.002.patch, HBASE-19906.branch-2.003.patch, > HBASE-19906.branch-2.003.patch, HBASE-19906.branch-2.004.patch, > HBASE-19906.branch-2.005.patch > > > TestZooKeeper is timing out causing hbase2 failures and breaking > HBASE-Flaky-Tests-branch2.0.0. > --- > Test set: org.apache.hadoop.hbase.TestZooKeeper > --- > Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 600.8 s <<< > FAILURE! - in org.apache.hadoop.hbase.TestZooKeeper > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.041 s <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 600 > seconds > at org.apache.hadoop.hbase.TestZooKeeper.after(TestZooKeeper.java:103) > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.046 s <<< ERROR! > java.lang.Exception: Appears to be stuck in thread > NIOServerCxn.Factory:0.0.0.0/0.0.0.0:59935 > Not always though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19906) TestZooKeeper Timeout
[ https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19906: -- Attachment: HBASE-19906.branch-2.004.patch > TestZooKeeper Timeout > - > > Key: HBASE-19906 > URL: https://issues.apache.org/jira/browse/HBASE-19906 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19906.branch-2.001.patch, > HBASE-19906.branch-2.002.patch, HBASE-19906.branch-2.003.patch, > HBASE-19906.branch-2.003.patch, HBASE-19906.branch-2.004.patch, > HBASE-19906.branch-2.005.patch > > > TestZooKeeper is timing out causing hbase2 failures and breaking > HBASE-Flaky-Tests-branch2.0.0. > --- > Test set: org.apache.hadoop.hbase.TestZooKeeper > --- > Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 600.8 s <<< > FAILURE! - in org.apache.hadoop.hbase.TestZooKeeper > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.041 s <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 600 > seconds > at org.apache.hadoop.hbase.TestZooKeeper.after(TestZooKeeper.java:103) > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.046 s <<< ERROR! > java.lang.Exception: Appears to be stuck in thread > NIOServerCxn.Factory:0.0.0.0/0.0.0.0:59935 > Not always though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19839) Flakey TestMergeTableRegionsProcedure & TestSplitTableRegionProcedure
[ https://issues.apache.org/jira/browse/HBASE-19839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348070#comment-16348070 ] stack commented on HBASE-19839: --- Just launched a run w/ proclimit at 10k and with docker container memory upped from default (4G it looks like) to 20G. Lets see how it does. > Flakey TestMergeTableRegionsProcedure & TestSplitTableRegionProcedure > - > > Key: HBASE-19839 > URL: https://issues.apache.org/jira/browse/HBASE-19839 > Project: HBase > Issue Type: Sub-task > Components: flakey, test >Reporter: stack >Assignee: Umesh Agashe >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: 0hbase-19839.master.004.patch, > 0hbase-19839.master.004.patch, 0hbase-19839.master.004.patch, > 0hbase-19839.master.004.patch, hbase-19839.master.001.patch, > hbase-19839.master.002.patch, hbase-19839.master.003.patch, > hbase-19839.master.003.patch, hbase-19839.master.003.patch, > hbase-19839.master.004.patch, hbase-19839.master.004.patch, > hbase-19839.master.004.patch, hbase-19839.master.004.patch, > hbase-19839.master.004.patch, hbase-19839.master.004.patch > > > Failing about 10% of the time: > [https://builds.apache.org/job/HBASE-Flaky-Tests-branch2.0/590/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.master.assignment.TestMergeTableRegionsProcedure.txt] > Its a good one. Probably an issue down deep. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19912) The flag "writeToWAL" of Region#checkAndRowMutate is useless
[ https://issues.apache.org/jira/browse/HBASE-19912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-19912: --- Labels: beginner (was: ) > The flag "writeToWAL" of Region#checkAndRowMutate is useless > > > Key: HBASE-19912 > URL: https://issues.apache.org/jira/browse/HBASE-19912 > Project: HBase > Issue Type: Improvement >Reporter: Chia-Ping Tsai >Priority: Minor > Labels: beginner > Fix For: 2.0.0-beta-2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19901) Up yetus proclimit on nightlies
[ https://issues.apache.org/jira/browse/HBASE-19901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348067#comment-16348067 ] stack commented on HBASE-19901: --- TODO: proclimit is still being worked on. memory for docker too. See tail of HBASE-19902 > Up yetus proclimit on nightlies > --- > > Key: HBASE-19901 > URL: https://issues.apache.org/jira/browse/HBASE-19901 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Attachments: HBASE-19901.master.001.patch > > > We're on 0.7.0 now which enforces limits meant to protect against runaway > processes. Default is 1000 procs. HBase test runs seem to consume almost 4k. > Up our proclimit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-19912) The flag "writeToWAL" of Region#checkAndRowMutate is useless
Chia-Ping Tsai created HBASE-19912: -- Summary: The flag "writeToWAL" of Region#checkAndRowMutate is useless Key: HBASE-19912 URL: https://issues.apache.org/jira/browse/HBASE-19912 Project: HBase Issue Type: Improvement Reporter: Chia-Ping Tsai Fix For: 2.0.0-beta-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19839) Flakey TestMergeTableRegionsProcedure & TestSplitTableRegionProcedure
[ https://issues.apache.org/jira/browse/HBASE-19839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19839: -- Attachment: hbase-19839.master.004.patch > Flakey TestMergeTableRegionsProcedure & TestSplitTableRegionProcedure > - > > Key: HBASE-19839 > URL: https://issues.apache.org/jira/browse/HBASE-19839 > Project: HBase > Issue Type: Sub-task > Components: flakey, test >Reporter: stack >Assignee: Umesh Agashe >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: 0hbase-19839.master.004.patch, > 0hbase-19839.master.004.patch, 0hbase-19839.master.004.patch, > 0hbase-19839.master.004.patch, hbase-19839.master.001.patch, > hbase-19839.master.002.patch, hbase-19839.master.003.patch, > hbase-19839.master.003.patch, hbase-19839.master.003.patch, > hbase-19839.master.004.patch, hbase-19839.master.004.patch, > hbase-19839.master.004.patch, hbase-19839.master.004.patch, > hbase-19839.master.004.patch, hbase-19839.master.004.patch > > > Failing about 10% of the time: > [https://builds.apache.org/job/HBASE-Flaky-Tests-branch2.0/590/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.master.assignment.TestMergeTableRegionsProcedure.txt] > Its a good one. Probably an issue down deep. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[
https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348065#comment-16348065
]
Hadoop QA commented on HBASE-19904:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
52s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 35 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
22s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
40s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
43s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
5s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
24s{color} | {color:red} hbase-server: The patch generated 11 new + 1133
unchanged - 16 fixed = 1144 total (was 1149) {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
45s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 5s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
30s{color} | {color:red} hbase-server generated 4 new + 2 unchanged - 0 fixed =
6 total (was 2) {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 23m 14s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 53m 47s{color}
| {color:red} hbase-mapreduce in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
52s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}122m 59s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.ipc.TestNettyRpcServer |
| | hadoop.hbase.regionserver.TestStoreFileRefresherChore |
| | hadoop.hbase.TestClientClusterStatus |
| | hadoop.hbase.mapreduce.TestTableInputFormatScan1 |
| | hadoop.hbase.mapreduce.TestCopyTable |
| | hadoop.hbase.snapshot.TestExportSnapshot |
| | hadoop.hbase.snapshot.TestMobExportSnapshot |
| | hadoop.hbase.mapreduce.TestTableInputFormatScan2 |
| | hadoop.hbase.snapshot.TestSecureExportSnapshot |
| | hadoop.hbase.mapreduce.TestMultiTableSnapshotInputFormat |
| | hadoop.hbase.mapreduce.TestImportTSVWithVisibilityLabels |
| | hadoop.hbase.replication.TestVerifyReplication |
| | hadoop.hbase.mapreduce.TestMultiTableInputFormat |
| | hadoop.hbase.mapreduce.TestImportTsv |
| |
[jira] [Commented] (HBASE-19876) The exception happening in converting pb mutation to hbase.mutation messes up the CellScanner
[
https://issues.apache.org/jira/browse/HBASE-19876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348062#comment-16348062
]
Chia-Ping Tsai commented on HBASE-19876:
v1 address [~yuzhih...@gmail.com]'s comment
> The exception happening in converting pb mutation to hbase.mutation messes up
> the CellScanner
> -
>
> Key: HBASE-19876
> URL: https://issues.apache.org/jira/browse/HBASE-19876
> Project: HBase
> Issue Type: Bug
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Critical
> Fix For: 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-2, 1.4.2
>
> Attachments: HBASE-19876.v0.patch, HBASE-19876.v1.patch
>
>
> {code:java}
> 2018-01-27 22:51:43,794 INFO [hconnection-0x3291b443-shared-pool11-t6]
> client.AsyncRequestFutureImpl(778): id=5, table=testQuotaStatusFromMaster3,
> attempt=6/16 failed=20ops, last
> exception=org.apache.hadoop.hbase.client.WrongRowIOException:
> org.apache.hadoop.hbase.client.WrongRowIOException: The row in xxx doesn't
> match the original one aaa
> at org.apache.hadoop.hbase.client.Mutation.add(Mutation.java:776)
> at org.apache.hadoop.hbase.client.Put.add(Put.java:282)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.toPut(ProtobufUtil.java:642)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doBatchOp(RSRpcServices.java:952)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doNonAtomicRegionMutation(RSRpcServices.java:896)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2591)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:41560)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:404)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304){code}
> I noticed this bug when testing the table space quota.
> When rs are converting pb mutation to hbase.mutation, the quota exception or
> cell exception may be thrown.
> {code}
> Unable to find source-code formatter for language:
> rsrpcservices#dobatchop.java. Available languages are: actionscript, ada,
> applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html,
> java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r,
> rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml for
> (ClientProtos.Action action: mutations) {
> MutationProto m = action.getMutation();
> Mutation mutation;
> if (m.getMutateType() == MutationType.PUT) {
> mutation = ProtobufUtil.toPut(m, cells);
> batchContainsPuts = true;
> } else {
> mutation = ProtobufUtil.toDelete(m, cells);
> batchContainsDelete = true;
> }
> mutationActionMap.put(mutation, action);
> mArray[i++] = mutation;
> checkCellSizeLimit(region, mutation);
> // Check if a space quota disallows this mutation
> spaceQuotaEnforcement.getPolicyEnforcement(region).check(mutation);
> quota.addMutation(mutation);
> }
> {code}
> rs has caught the exception but it doesn't have the cellscanner skip the
> failed cells.
> {code:java}
> } catch (IOException ie) {
> if (atomic) {
> throw ie;
> }
> for (Action mutation : mutations) {
> builder.addResultOrException(getResultOrException(ie,
> mutation.getIndex()));
> }
> }
> {code}
> The bug results in the WrongRowIOException to remaining mutations since they
> refer to invalid cells.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-19876) The exception happening in converting pb mutation to hbase.mutation messes up the CellScanner
[
https://issues.apache.org/jira/browse/HBASE-19876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19876:
---
Attachment: HBASE-19876.v1.patch
> The exception happening in converting pb mutation to hbase.mutation messes up
> the CellScanner
> -
>
> Key: HBASE-19876
> URL: https://issues.apache.org/jira/browse/HBASE-19876
> Project: HBase
> Issue Type: Bug
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Critical
> Fix For: 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-2, 1.4.2
>
> Attachments: HBASE-19876.v0.patch, HBASE-19876.v1.patch
>
>
> {code:java}
> 2018-01-27 22:51:43,794 INFO [hconnection-0x3291b443-shared-pool11-t6]
> client.AsyncRequestFutureImpl(778): id=5, table=testQuotaStatusFromMaster3,
> attempt=6/16 failed=20ops, last
> exception=org.apache.hadoop.hbase.client.WrongRowIOException:
> org.apache.hadoop.hbase.client.WrongRowIOException: The row in xxx doesn't
> match the original one aaa
> at org.apache.hadoop.hbase.client.Mutation.add(Mutation.java:776)
> at org.apache.hadoop.hbase.client.Put.add(Put.java:282)
> at
> org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.toPut(ProtobufUtil.java:642)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doBatchOp(RSRpcServices.java:952)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doNonAtomicRegionMutation(RSRpcServices.java:896)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2591)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:41560)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:404)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304){code}
> I noticed this bug when testing the table space quota.
> When rs are converting pb mutation to hbase.mutation, the quota exception or
> cell exception may be thrown.
> {code}
> Unable to find source-code formatter for language:
> rsrpcservices#dobatchop.java. Available languages are: actionscript, ada,
> applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html,
> java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r,
> rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml for
> (ClientProtos.Action action: mutations) {
> MutationProto m = action.getMutation();
> Mutation mutation;
> if (m.getMutateType() == MutationType.PUT) {
> mutation = ProtobufUtil.toPut(m, cells);
> batchContainsPuts = true;
> } else {
> mutation = ProtobufUtil.toDelete(m, cells);
> batchContainsDelete = true;
> }
> mutationActionMap.put(mutation, action);
> mArray[i++] = mutation;
> checkCellSizeLimit(region, mutation);
> // Check if a space quota disallows this mutation
> spaceQuotaEnforcement.getPolicyEnforcement(region).check(mutation);
> quota.addMutation(mutation);
> }
> {code}
> rs has caught the exception but it doesn't have the cellscanner skip the
> failed cells.
> {code:java}
> } catch (IOException ie) {
> if (atomic) {
> throw ie;
> }
> for (Action mutation : mutations) {
> builder.addResultOrException(getResultOrException(ie,
> mutation.getIndex()));
> }
> }
> {code}
> The bug results in the WrongRowIOException to remaining mutations since they
> refer to invalid cells.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-19839) Flakey TestMergeTableRegionsProcedure & TestSplitTableRegionProcedure
[ https://issues.apache.org/jira/browse/HBASE-19839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19839: -- Attachment: hbase-19839.master.004.patch > Flakey TestMergeTableRegionsProcedure & TestSplitTableRegionProcedure > - > > Key: HBASE-19839 > URL: https://issues.apache.org/jira/browse/HBASE-19839 > Project: HBase > Issue Type: Sub-task > Components: flakey, test >Reporter: stack >Assignee: Umesh Agashe >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: 0hbase-19839.master.004.patch, > 0hbase-19839.master.004.patch, 0hbase-19839.master.004.patch, > 0hbase-19839.master.004.patch, hbase-19839.master.001.patch, > hbase-19839.master.002.patch, hbase-19839.master.003.patch, > hbase-19839.master.003.patch, hbase-19839.master.003.patch, > hbase-19839.master.004.patch, hbase-19839.master.004.patch, > hbase-19839.master.004.patch, hbase-19839.master.004.patch, > hbase-19839.master.004.patch > > > Failing about 10% of the time: > [https://builds.apache.org/job/HBASE-Flaky-Tests-branch2.0/590/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.master.assignment.TestMergeTableRegionsProcedure.txt] > Its a good one. Probably an issue down deep. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19897) RowMutations should follow the fluent pattern
[
https://issues.apache.org/jira/browse/HBASE-19897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19897:
---
Status: Patch Available (was: Reopened)
> RowMutations should follow the fluent pattern
> -
>
> Key: HBASE-19897
> URL: https://issues.apache.org/jira/browse/HBASE-19897
> Project: HBase
> Issue Type: New Feature
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Minor
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19897.v0.patch, HBASE-19897.v1.patch
>
>
> Other row ops, including {{Put}}, {{Delete}}, {{Get}}, {{Scan}}, do have the
> fluent interface. Also, Changing the return type from {{Void}} to
> {{RowMutations}} won't break the API BC (unless someone has interest in
> {{Void}} object...)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-19897) RowMutations should follow the fluent pattern
[
https://issues.apache.org/jira/browse/HBASE-19897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19897:
---
Attachment: HBASE-19897.v1.patch
> RowMutations should follow the fluent pattern
> -
>
> Key: HBASE-19897
> URL: https://issues.apache.org/jira/browse/HBASE-19897
> Project: HBase
> Issue Type: New Feature
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Minor
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19897.v0.patch, HBASE-19897.v1.patch
>
>
> Other row ops, including {{Put}}, {{Delete}}, {{Get}}, {{Scan}}, do have the
> fluent interface. Also, Changing the return type from {{Void}} to
> {{RowMutations}} won't break the API BC (unless someone has interest in
> {{Void}} object...)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (HBASE-19897) RowMutations should follow the fluent pattern
[
https://issues.apache.org/jira/browse/HBASE-19897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai reopened HBASE-19897:
We can apply the mutation to the adder as BufferedMutator does
> RowMutations should follow the fluent pattern
> -
>
> Key: HBASE-19897
> URL: https://issues.apache.org/jira/browse/HBASE-19897
> Project: HBase
> Issue Type: New Feature
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Minor
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19897.v0.patch
>
>
> Other row ops, including {{Put}}, {{Delete}}, {{Get}}, {{Scan}}, do have the
> fluent interface. Also, Changing the return type from {{Void}} to
> {{RowMutations}} won't break the API BC (unless someone has interest in
> {{Void}} object...)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19906) TestZooKeeper Timeout
[ https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348046#comment-16348046 ] stack commented on HBASE-19906: --- [~appy] Yeah, Master startup (Master?) is finicky. Needs a redo (See HBASE-19831). Here's some spew on the topic: Master-is-a-RegionServer (subclass) was hacked in. So much of Master function happens in the startup phase before we get to 'run'. Master waits on RegionServers in startup before moving on to run. Meta is also assigned as part of Master startup as are Namespace tables. So, Master startup cannot complete w/o other servers reporting in and after it has done a bunch of RPC. Master also puts up 'services' on startup, many of them. How Services are started depends. Chores are done one way. ZK-using services another. We started to subclass Guava Service -- which has lots of nice facility (doing it async, reporting status, common form and start/stop...). And so on. So, lots of Services. Some you shutdown. Some you Stop. Some go down when cluster is set to down. Others only go down after an abort and when we are in the Server exit sequence. Some Services need interrupt (RPC or sleeping threads). Some have a latch so they are for sure single-stepping it, that must be undone. Others are synchronized (interesting recent one where Master does reportForDuty to itself but it has locked itself out when Master is supposed to host Regions). This makes Master startup a long sequence of ops, waits on external service Would be nice to redo after years of accumulation. One nice recent redo was done by [~uagashe]... He took all the places we did region assign -- there were at least two versions of this function -- and he put them into a single Pv2 Procedure with the name RecoverMetaProcedure -- we should rename it (smile), make it prettier -- but now meta assign is done one way only... its great -- in this patch we actually fix a bug in hbase:meta assign ... and in one place only (This Procedure doesn't work for meta region replicas though... another hack-in). We need more of this pattern... With the Procedure redo, we can move meta assign out of Master signup. Then we won't have to wait on Regions to come in before we get to the 'run' phase. Once in run phase, shutdown is no longer special-casing -- i.e. the check for stop in startup as this patch adds back -- or other fixups so Master startup sequence notices we are in cluster shutdown and it needs to go down. > TestZooKeeper Timeout > - > > Key: HBASE-19906 > URL: https://issues.apache.org/jira/browse/HBASE-19906 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19906.branch-2.001.patch, > HBASE-19906.branch-2.002.patch, HBASE-19906.branch-2.003.patch, > HBASE-19906.branch-2.003.patch > > > TestZooKeeper is timing out causing hbase2 failures and breaking > HBASE-Flaky-Tests-branch2.0.0. > --- > Test set: org.apache.hadoop.hbase.TestZooKeeper > --- > Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 600.8 s <<< > FAILURE! - in org.apache.hadoop.hbase.TestZooKeeper > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.041 s <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 600 > seconds > at org.apache.hadoop.hbase.TestZooKeeper.after(TestZooKeeper.java:103) > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.046 s <<< ERROR! > java.lang.Exception: Appears to be stuck in thread > NIOServerCxn.Factory:0.0.0.0/0.0.0.0:59935 > Not always though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19906) TestZooKeeper Timeout
[
https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348036#comment-16348036
]
Hadoop QA commented on HBASE-19906:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
32s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} branch-2 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
41s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
46s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
15s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
41s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} branch-2 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
21s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 37s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 22m 48s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
51s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 61m 18s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestQosFunction |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:9f2f2db |
| JIRA Issue | HBASE-19906 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12908721/HBASE-19906.branch-2.003.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux b94993a84008 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | branch-2 / 4c210eb212 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/11310/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/11310/testReport/ |
| Max. process+thread count | 657 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console
[jira] [Comment Edited] (HBASE-19902) Current Jenkins Madness: OOME, can't start minihbasecluster, etc.
[
https://issues.apache.org/jira/browse/HBASE-19902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348032#comment-16348032
]
Allen Wittenauer edited comment on HBASE-19902 at 2/1/18 5:28 AM:
--
Awesome work! Thanks [~stack].
I spent some time looking over the output of various jobs. At this point, I'm
not entirely convinced that hbase is hitting the proc limit [*]. I'm more
inclined to think that it's actually hitting the Docker memory. By chance, did
anyone up the --dockermemlimit setting? If not, try --dockermemlimit=20g .
That should be less than half of the node's RAM.
EDIT:
* - at least, at anything past the 5k mark.
was (Author: aw):
Awesome work! Thanks [~stack].
I spent some time looking over the output of various jobs. At this point, I'm
not entirely convinced that hbase is hitting the proc limit. I'm more inclined
to think that it's actually hitting the Docker memory. By chance, did anyone up
the --dockermemlimit setting? If not, try --dockermemlimit=20g . That should
be less than half of the node's RAM.
> Current Jenkins Madness: OOME, can't start minihbasecluster, etc.
> -
>
> Key: HBASE-19902
> URL: https://issues.apache.org/jira/browse/HBASE-19902
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
>Priority: Major
> Attachments: HBASE-19902.temporary-2.001.patch
>
>
> Trying to figure what is going on w/ jenkins build
> Changed the hadoopqa config to output long process listing rather than just
> 'java'...
> I can't get loadavg... tried dumping /proc...
> /tmp/jenkins6485196190911961762.sh: line 48: /loadavg: Permission denied
> Looking at https://builds.apache.org/job/PreCommit-HBASE-Build/11273/console,
> see 7 java processes running on H2. Extra args on ps may help here whether it
> zombies of us.
> Test run was find then fell into hbase-server second part and soon after
> started failing..
> https://builds.apache.org/job/PreCommit-HBASE-Build/11273/artifact/patchprocess/patch-unit-hbase-server.txt
> Looking at first test failure... this is where main thread is, trying to get
> thread info:
> {code}
> Thread 23 (Time-limited test):
> State: RUNNABLE
> Blocked count: 118
> Waited count: 58
> Stack:
> sun.management.ThreadImpl.getThreadInfo1(Native Method)
> sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:178)
> sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:139)
>
> org.apache.hadoop.util.ReflectionUtils.printThreadInfo(ReflectionUtils.java:168)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:498)
>
> org.apache.hadoop.hbase.util.Threads$PrintThreadInfoLazyHolder$1.printThreadInfo(Threads.java:294)
> org.apache.hadoop.hbase.util.Threads.printThreadInfo(Threads.java:341)
>
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:191)
>
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:391)
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:262)
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:119)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1025)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:971)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:842)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:824)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:806)
>
> org.apache.hadoop.hbase.AcidGuaranteesTestBase.setUpBeforeClass(AcidGuaranteesTestBase.java:61)
> {code}
> Master is not coming up
> {code}
> 2018-01-31 02:22:31,474 ERROR [Time-limited test]
> hbase.MiniHBaseCluster(267): Error starting cluster
> java.lang.RuntimeException: Master not active after 3ms
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:192)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:391)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:262)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:119)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1025)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:971)
> at
>
[jira] [Commented] (HBASE-19902) Current Jenkins Madness: OOME, can't start minihbasecluster, etc.
[
https://issues.apache.org/jira/browse/HBASE-19902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348032#comment-16348032
]
Allen Wittenauer commented on HBASE-19902:
--
Awesome work! Thanks [~stack].
I spent some time looking over the output of various jobs. At this point, I'm
not entirely convinced that hbase is hitting the proc limit. I'm more inclined
to think that it's actually hitting the Docker memory. By chance, did anyone up
the --dockermemlimit setting? If not, try --dockermemlimit=20g . That should
be less than half of the node's RAM.
> Current Jenkins Madness: OOME, can't start minihbasecluster, etc.
> -
>
> Key: HBASE-19902
> URL: https://issues.apache.org/jira/browse/HBASE-19902
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
>Priority: Major
> Attachments: HBASE-19902.temporary-2.001.patch
>
>
> Trying to figure what is going on w/ jenkins build
> Changed the hadoopqa config to output long process listing rather than just
> 'java'...
> I can't get loadavg... tried dumping /proc...
> /tmp/jenkins6485196190911961762.sh: line 48: /loadavg: Permission denied
> Looking at https://builds.apache.org/job/PreCommit-HBASE-Build/11273/console,
> see 7 java processes running on H2. Extra args on ps may help here whether it
> zombies of us.
> Test run was find then fell into hbase-server second part and soon after
> started failing..
> https://builds.apache.org/job/PreCommit-HBASE-Build/11273/artifact/patchprocess/patch-unit-hbase-server.txt
> Looking at first test failure... this is where main thread is, trying to get
> thread info:
> {code}
> Thread 23 (Time-limited test):
> State: RUNNABLE
> Blocked count: 118
> Waited count: 58
> Stack:
> sun.management.ThreadImpl.getThreadInfo1(Native Method)
> sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:178)
> sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:139)
>
> org.apache.hadoop.util.ReflectionUtils.printThreadInfo(ReflectionUtils.java:168)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:498)
>
> org.apache.hadoop.hbase.util.Threads$PrintThreadInfoLazyHolder$1.printThreadInfo(Threads.java:294)
> org.apache.hadoop.hbase.util.Threads.printThreadInfo(Threads.java:341)
>
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:191)
>
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:391)
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:262)
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:119)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1025)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:971)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:842)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:824)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:806)
>
> org.apache.hadoop.hbase.AcidGuaranteesTestBase.setUpBeforeClass(AcidGuaranteesTestBase.java:61)
> {code}
> Master is not coming up
> {code}
> 2018-01-31 02:22:31,474 ERROR [Time-limited test]
> hbase.MiniHBaseCluster(267): Error starting cluster
> java.lang.RuntimeException: Master not active after 3ms
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:192)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:391)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:262)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:119)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1025)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:971)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:842)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:824)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:806)
> at
> org.apache.hadoop.hbase.AcidGuaranteesTestBase.setUpBeforeClass(AcidGuaranteesTestBase.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Commented] (HBASE-19908) TestCoprocessorShortCircuitRPC Timeout....
[ https://issues.apache.org/jira/browse/HBASE-19908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348029#comment-16348029 ] Duo Zhang commented on HBASE-19908: --- Yes, only up small to 60s without changing others. > TestCoprocessorShortCircuitRPC Timeout > -- > > Key: HBASE-19908 > URL: https://issues.apache.org/jira/browse/HBASE-19908 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Priority: Major > Attachments: HBASE-19908.master.001.patch > > > Timedout in HBASE-19906 > Comparing a local run (16seconds total) to a timed out run up on jenkins, I > see it takes my local test 5 seconds to get the STOPPED server log line. On > jenkins in this timed out test it takes 30 seconds. Test is still running > when it is killed. Let me make it a medium test. > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/lastCompletedBuild/testReport/org.apache.hadoop.hbase.coprocessor/TestCoprocessorShortCircuitRPC/org_apache_hadoop_hbase_coprocessor_TestCoprocessorShortCircuitRPC/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19908) TestCoprocessorShortCircuitRPC Timeout....
[
https://issues.apache.org/jira/browse/HBASE-19908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348027#comment-16348027
]
stack commented on HBASE-19908:
---
Maybe we can increase the time limit a bit?
Refguide has this:
http://hbase.apache.org/book.html#hbase.unittests
15s/50s/Everything else...
Funny. Says small tests should not execute minicluster.
Then HBaseClassTestRule has
for (Class c : categories[0].value()) {
if (c == SmallTests.class) {
// See SmallTests. Supposed to run 15 seconds.
return 30;
} else if (c == MediumTests.class) {
// See MediumTests. Supposed to run 50 seconds.
return 180;
} else if (c == LargeTests.class) {
// Let large tests have a ten minute timeout.
return TimeUnit.MINUTES.toSeconds(10);
this is time for each individual method in the test suite (as I read it...
not for whole class).
So, we've already gone up from the 15 seconds we talk of in the refguide?
Or, just up small tests to 60seconds? Leave the rest (i like the ten minutes
total).
[~Apache9]
> TestCoprocessorShortCircuitRPC Timeout
> --
>
> Key: HBASE-19908
> URL: https://issues.apache.org/jira/browse/HBASE-19908
> Project: HBase
> Issue Type: Sub-task
>Reporter: stack
>Priority: Major
> Attachments: HBASE-19908.master.001.patch
>
>
> Timedout in HBASE-19906
> Comparing a local run (16seconds total) to a timed out run up on jenkins, I
> see it takes my local test 5 seconds to get the STOPPED server log line. On
> jenkins in this timed out test it takes 30 seconds. Test is still running
> when it is killed. Let me make it a medium test.
> https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/lastCompletedBuild/testReport/org.apache.hadoop.hbase.coprocessor/TestCoprocessorShortCircuitRPC/org_apache_hadoop_hbase_coprocessor_TestCoprocessorShortCircuitRPC/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19906) TestZooKeeper Timeout
[ https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348018#comment-16348018 ] Appy commented on HBASE-19906: -- I have a feeling that something is still off, that there's still some corner case which is not being handled. Let me research more...figure out why it does/doesn't work. In meantime, go ahead with the patch. > TestZooKeeper Timeout > - > > Key: HBASE-19906 > URL: https://issues.apache.org/jira/browse/HBASE-19906 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19906.branch-2.001.patch, > HBASE-19906.branch-2.002.patch, HBASE-19906.branch-2.003.patch, > HBASE-19906.branch-2.003.patch > > > TestZooKeeper is timing out causing hbase2 failures and breaking > HBASE-Flaky-Tests-branch2.0.0. > --- > Test set: org.apache.hadoop.hbase.TestZooKeeper > --- > Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 600.8 s <<< > FAILURE! - in org.apache.hadoop.hbase.TestZooKeeper > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.041 s <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 600 > seconds > at org.apache.hadoop.hbase.TestZooKeeper.after(TestZooKeeper.java:103) > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.046 s <<< ERROR! > java.lang.Exception: Appears to be stuck in thread > NIOServerCxn.Factory:0.0.0.0/0.0.0.0:59935 > Not always though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348014#comment-16348014 ] Duo Zhang commented on HBASE-19904: --- The magic is the number. If it is the same when reading from left and from right, you can get the fish trophy. > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v3.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348003#comment-16348003 ] stack commented on HBASE-19904: --- How do I get a fish trophy? The failed tests should be fixed now. > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v3.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19908) TestCoprocessorShortCircuitRPC Timeout....
[ https://issues.apache.org/jira/browse/HBASE-19908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348002#comment-16348002 ] Duo Zhang commented on HBASE-19908: --- Maybe we can increase the time limit a bit? For example, to 1 minute? I see that some tests which do not start a mini cluster could also timeout... > TestCoprocessorShortCircuitRPC Timeout > -- > > Key: HBASE-19908 > URL: https://issues.apache.org/jira/browse/HBASE-19908 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Priority: Major > Attachments: HBASE-19908.master.001.patch > > > Timedout in HBASE-19906 > Comparing a local run (16seconds total) to a timed out run up on jenkins, I > see it takes my local test 5 seconds to get the STOPPED server log line. On > jenkins in this timed out test it takes 30 seconds. Test is still running > when it is killed. Let me make it a medium test. > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/lastCompletedBuild/testReport/org.apache.hadoop.hbase.coprocessor/TestCoprocessorShortCircuitRPC/org_apache_hadoop_hbase_coprocessor_TestCoprocessorShortCircuitRPC/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19902) Current Jenkins Madness: OOME, can't start minihbasecluster, etc.
[
https://issues.apache.org/jira/browse/HBASE-19902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348001#comment-16348001
]
stack commented on HBASE-19902:
---
So, on hadoopqa, I tried upping the proclimit gradually. 6k did not seem to be
enough, nor 8k (or too many concurrent builds also using up processes).
Working on our proc limit in test suite is a project we need to work on. Our
hadoopqa dumps out some more reporting on what is also running at test start...
you should be able to see any concurrent heavyweights like other hbase test
suites if you look in build artifacts under 'computer'. Will file a follow-up
to work on our resource usage as tests run (still too many therads!!!). For now
hadoopqa is set to 10k which is kinda useless going by [~aw]'s assessment of
limit and how counts are done. Thats where we are at. Will see how it does over
next few days.
> Current Jenkins Madness: OOME, can't start minihbasecluster, etc.
> -
>
> Key: HBASE-19902
> URL: https://issues.apache.org/jira/browse/HBASE-19902
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: stack
>Priority: Major
> Attachments: HBASE-19902.temporary-2.001.patch
>
>
> Trying to figure what is going on w/ jenkins build
> Changed the hadoopqa config to output long process listing rather than just
> 'java'...
> I can't get loadavg... tried dumping /proc...
> /tmp/jenkins6485196190911961762.sh: line 48: /loadavg: Permission denied
> Looking at https://builds.apache.org/job/PreCommit-HBASE-Build/11273/console,
> see 7 java processes running on H2. Extra args on ps may help here whether it
> zombies of us.
> Test run was find then fell into hbase-server second part and soon after
> started failing..
> https://builds.apache.org/job/PreCommit-HBASE-Build/11273/artifact/patchprocess/patch-unit-hbase-server.txt
> Looking at first test failure... this is where main thread is, trying to get
> thread info:
> {code}
> Thread 23 (Time-limited test):
> State: RUNNABLE
> Blocked count: 118
> Waited count: 58
> Stack:
> sun.management.ThreadImpl.getThreadInfo1(Native Method)
> sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:178)
> sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:139)
>
> org.apache.hadoop.util.ReflectionUtils.printThreadInfo(ReflectionUtils.java:168)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:498)
>
> org.apache.hadoop.hbase.util.Threads$PrintThreadInfoLazyHolder$1.printThreadInfo(Threads.java:294)
> org.apache.hadoop.hbase.util.Threads.printThreadInfo(Threads.java:341)
>
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:191)
>
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:391)
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:262)
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:119)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1025)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:971)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:842)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:824)
>
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:806)
>
> org.apache.hadoop.hbase.AcidGuaranteesTestBase.setUpBeforeClass(AcidGuaranteesTestBase.java:61)
> {code}
> Master is not coming up
> {code}
> 2018-01-31 02:22:31,474 ERROR [Time-limited test]
> hbase.MiniHBaseCluster(267): Error starting cluster
> java.lang.RuntimeException: Master not active after 3ms
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:192)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:391)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:262)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:119)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1025)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:971)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:842)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:824)
> at
>
[jira] [Commented] (HBASE-19906) TestZooKeeper Timeout
[ https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347998#comment-16347998 ] stack commented on HBASE-19906: --- Retry of .003 after HBASE-19911 has gone in which should take care of the above faliures. > TestZooKeeper Timeout > - > > Key: HBASE-19906 > URL: https://issues.apache.org/jira/browse/HBASE-19906 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19906.branch-2.001.patch, > HBASE-19906.branch-2.002.patch, HBASE-19906.branch-2.003.patch, > HBASE-19906.branch-2.003.patch > > > TestZooKeeper is timing out causing hbase2 failures and breaking > HBASE-Flaky-Tests-branch2.0.0. > --- > Test set: org.apache.hadoop.hbase.TestZooKeeper > --- > Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 600.8 s <<< > FAILURE! - in org.apache.hadoop.hbase.TestZooKeeper > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.041 s <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 600 > seconds > at org.apache.hadoop.hbase.TestZooKeeper.after(TestZooKeeper.java:103) > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.046 s <<< ERROR! > java.lang.Exception: Appears to be stuck in thread > NIOServerCxn.Factory:0.0.0.0/0.0.0.0:59935 > Not always though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19906) TestZooKeeper Timeout
[ https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347996#comment-16347996 ] stack commented on HBASE-19906: --- bq. What if we do go that far? ... then the change in AM where we will carry on to cancel the ongoing RecoverMetaProcedure though the ServerName in the RegionNode may be null, should take care of that (it 'cancels' the ongoing assign... which makes the procedure get control again, notice the shutdown and exit) Keep asking questions. > TestZooKeeper Timeout > - > > Key: HBASE-19906 > URL: https://issues.apache.org/jira/browse/HBASE-19906 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19906.branch-2.001.patch, > HBASE-19906.branch-2.002.patch, HBASE-19906.branch-2.003.patch, > HBASE-19906.branch-2.003.patch > > > TestZooKeeper is timing out causing hbase2 failures and breaking > HBASE-Flaky-Tests-branch2.0.0. > --- > Test set: org.apache.hadoop.hbase.TestZooKeeper > --- > Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 600.8 s <<< > FAILURE! - in org.apache.hadoop.hbase.TestZooKeeper > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.041 s <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 600 > seconds > at org.apache.hadoop.hbase.TestZooKeeper.after(TestZooKeeper.java:103) > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.046 s <<< ERROR! > java.lang.Exception: Appears to be stuck in thread > NIOServerCxn.Factory:0.0.0.0/0.0.0.0:59935 > Not always though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19906) TestZooKeeper Timeout
[ https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19906: -- Attachment: HBASE-19906.branch-2.003.patch > TestZooKeeper Timeout > - > > Key: HBASE-19906 > URL: https://issues.apache.org/jira/browse/HBASE-19906 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19906.branch-2.001.patch, > HBASE-19906.branch-2.002.patch, HBASE-19906.branch-2.003.patch, > HBASE-19906.branch-2.003.patch > > > TestZooKeeper is timing out causing hbase2 failures and breaking > HBASE-Flaky-Tests-branch2.0.0. > --- > Test set: org.apache.hadoop.hbase.TestZooKeeper > --- > Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 600.8 s <<< > FAILURE! - in org.apache.hadoop.hbase.TestZooKeeper > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.041 s <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 600 > seconds > at org.apache.hadoop.hbase.TestZooKeeper.after(TestZooKeeper.java:103) > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.046 s <<< ERROR! > java.lang.Exception: Appears to be stuck in thread > NIOServerCxn.Factory:0.0.0.0/0.0.0.0:59935 > Not always though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19911) Convert some tests from small to medium because they are timing out: TestNettyRpcServer, TestClientClusterStatus, TestCheckTestClasses
[ https://issues.apache.org/jira/browse/HBASE-19911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347995#comment-16347995 ] stack commented on HBASE-19911: --- Addendum converts over TestCheckTestClasses to be medium test too.. It timed out at 30 seconds but doesn't log anything. Guessing similar issue. > Convert some tests from small to medium because they are timing out: > TestNettyRpcServer, TestClientClusterStatus, TestCheckTestClasses > -- > > Key: HBASE-19911 > URL: https://issues.apache.org/jira/browse/HBASE-19911 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19911.branch-2.001.patch > > > Found some more timeouts of small tests. > TestNettyRpcServer > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11307/testReport/junit/org.apache.hadoop.hbase.ipc/TestNettyRpcServer/org_apache_hadoop_hbase_ipc_TestNettyRpcServer/ > On local machine takes 14 seconds to run 1 test. In the above failure..., the > test needs another second or so to complete It has been running 30 > seconds. > Starts a minihbasecluster, creates a table, then shuts down. Shouldn't even > take 3 seconds but thats another story. > TestClientClusterStatus is a small test that starts 5 regionservers and 3 > masters. Then does some stopping of servers, etc. > .. in same test run... > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11307/testReport/junit/org.apache.hadoop.hbase/TestClientClusterStatus/org_apache_hadoop_hbase_TestClientClusterStatus/ > ... it timed out after 30 seconds. Its almost done w/ shutdown but not quite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19911) Convert some tests from small to medium because they are timing out: TestNettyRpcServer, TestClientClusterStatus, TestCheckTestClasses
[ https://issues.apache.org/jira/browse/HBASE-19911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19911: -- Summary: Convert some tests from small to medium because they are timing out: TestNettyRpcServer, TestClientClusterStatus, TestCheckTestClasses (was: Convert some tests from small to medium because they are timing out: TestNettyRpcServer, TestClientClusterStatus) > Convert some tests from small to medium because they are timing out: > TestNettyRpcServer, TestClientClusterStatus, TestCheckTestClasses > -- > > Key: HBASE-19911 > URL: https://issues.apache.org/jira/browse/HBASE-19911 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19911.branch-2.001.patch > > > Found some more timeouts of small tests. > TestNettyRpcServer > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11307/testReport/junit/org.apache.hadoop.hbase.ipc/TestNettyRpcServer/org_apache_hadoop_hbase_ipc_TestNettyRpcServer/ > On local machine takes 14 seconds to run 1 test. In the above failure..., the > test needs another second or so to complete It has been running 30 > seconds. > Starts a minihbasecluster, creates a table, then shuts down. Shouldn't even > take 3 seconds but thats another story. > TestClientClusterStatus is a small test that starts 5 regionservers and 3 > masters. Then does some stopping of servers, etc. > .. in same test run... > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11307/testReport/junit/org.apache.hadoop.hbase/TestClientClusterStatus/org_apache_hadoop_hbase_TestClientClusterStatus/ > ... it timed out after 30 seconds. Its almost done w/ shutdown but not quite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19911) Convert some tests from small to medium because they are timing out: TestNettyRpcServer, TestClientClusterStatus
[ https://issues.apache.org/jira/browse/HBASE-19911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347994#comment-16347994 ] stack commented on HBASE-19911: --- .001 is what I pushed to master and branch-2. Leaving open until for sure this is fixed. > Convert some tests from small to medium because they are timing out: > TestNettyRpcServer, TestClientClusterStatus > > > Key: HBASE-19911 > URL: https://issues.apache.org/jira/browse/HBASE-19911 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19911.branch-2.001.patch > > > Found some more timeouts of small tests. > TestNettyRpcServer > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11307/testReport/junit/org.apache.hadoop.hbase.ipc/TestNettyRpcServer/org_apache_hadoop_hbase_ipc_TestNettyRpcServer/ > On local machine takes 14 seconds to run 1 test. In the above failure..., the > test needs another second or so to complete It has been running 30 > seconds. > Starts a minihbasecluster, creates a table, then shuts down. Shouldn't even > take 3 seconds but thats another story. > TestClientClusterStatus is a small test that starts 5 regionservers and 3 > masters. Then does some stopping of servers, etc. > .. in same test run... > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11307/testReport/junit/org.apache.hadoop.hbase/TestClientClusterStatus/org_apache_hadoop_hbase_TestClientClusterStatus/ > ... it timed out after 30 seconds. Its almost done w/ shutdown but not quite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19911) Convert some tests from small to medium because they are timing out: TestNettyRpcServer, TestClientClusterStatus
[ https://issues.apache.org/jira/browse/HBASE-19911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19911: -- Attachment: HBASE-19911.branch-2.001.patch > Convert some tests from small to medium because they are timing out: > TestNettyRpcServer, TestClientClusterStatus > > > Key: HBASE-19911 > URL: https://issues.apache.org/jira/browse/HBASE-19911 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19911.branch-2.001.patch > > > Found some more timeouts of small tests. > TestNettyRpcServer > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11307/testReport/junit/org.apache.hadoop.hbase.ipc/TestNettyRpcServer/org_apache_hadoop_hbase_ipc_TestNettyRpcServer/ > On local machine takes 14 seconds to run 1 test. In the above failure..., the > test needs another second or so to complete It has been running 30 > seconds. > Starts a minihbasecluster, creates a table, then shuts down. Shouldn't even > take 3 seconds but thats another story. > TestClientClusterStatus is a small test that starts 5 regionservers and 3 > masters. Then does some stopping of servers, etc. > .. in same test run... > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11307/testReport/junit/org.apache.hadoop.hbase/TestClientClusterStatus/org_apache_hadoop_hbase_TestClientClusterStatus/ > ... it timed out after 30 seconds. Its almost done w/ shutdown but not quite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19911) Convert some tests from small to medium because they are timing out: TestNettyRpcServer, TestClientClusterStatus
[ https://issues.apache.org/jira/browse/HBASE-19911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19911: -- Summary: Convert some tests from small to medium because they are timing out: TestNettyRpcServer, TestClientClusterStatus (was: Convert some tests from small to medium because they are timing out: TestNettyRpcServer) > Convert some tests from small to medium because they are timing out: > TestNettyRpcServer, TestClientClusterStatus > > > Key: HBASE-19911 > URL: https://issues.apache.org/jira/browse/HBASE-19911 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > > Found some more timeouts of small tests. > TestNettyRpcServer > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11307/testReport/junit/org.apache.hadoop.hbase.ipc/TestNettyRpcServer/org_apache_hadoop_hbase_ipc_TestNettyRpcServer/ > On local machine takes 14 seconds to run 1 test. In the above failure..., the > test needs another second or so to complete It has been running 30 > seconds. > Starts a minihbasecluster, creates a table, then shuts down. Shouldn't even > take 3 seconds but thats another story. > TestClientClusterStatus is a small test that starts 5 regionservers and 3 > masters. Then does some stopping of servers, etc. > .. in same test run... > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11307/testReport/junit/org.apache.hadoop.hbase/TestClientClusterStatus/org_apache_hadoop_hbase_TestClientClusterStatus/ > ... it timed out after 30 seconds. Its almost done w/ shutdown but not quite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-19911) Convert some tests from small to medium because they are timing out: TestNettyRpcServer
stack created HBASE-19911: - Summary: Convert some tests from small to medium because they are timing out: TestNettyRpcServer Key: HBASE-19911 URL: https://issues.apache.org/jira/browse/HBASE-19911 Project: HBase Issue Type: Sub-task Reporter: stack Assignee: stack Fix For: 2.0.0-beta-2 Found some more timeouts of small tests. TestNettyRpcServer https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11307/testReport/junit/org.apache.hadoop.hbase.ipc/TestNettyRpcServer/org_apache_hadoop_hbase_ipc_TestNettyRpcServer/ On local machine takes 14 seconds to run 1 test. In the above failure..., the test needs another second or so to complete It has been running 30 seconds. Starts a minihbasecluster, creates a table, then shuts down. Shouldn't even take 3 seconds but thats another story. TestClientClusterStatus is a small test that starts 5 regionservers and 3 masters. Then does some stopping of servers, etc. .. in same test run... https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11307/testReport/junit/org.apache.hadoop.hbase/TestClientClusterStatus/org_apache_hadoop_hbase_TestClientClusterStatus/ ... it timed out after 30 seconds. Its almost done w/ shutdown but not quite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347988#comment-16347988 ] Duo Zhang commented on HBASE-19904: --- Review board link: https://reviews.apache.org/r/65456/ Duo Zhang got a fish trophy! > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v3.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19906) TestZooKeeper Timeout
[ https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347987#comment-16347987 ] Appy commented on HBASE-19906: -- +1 since you know what's going on here. But some clarification questions to help myself understand. bq. We usually wouldn't get as far as recovering meta because the isStopped would have tripped. What if we do go that far? > TestZooKeeper Timeout > - > > Key: HBASE-19906 > URL: https://issues.apache.org/jira/browse/HBASE-19906 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19906.branch-2.001.patch, > HBASE-19906.branch-2.002.patch, HBASE-19906.branch-2.003.patch > > > TestZooKeeper is timing out causing hbase2 failures and breaking > HBASE-Flaky-Tests-branch2.0.0. > --- > Test set: org.apache.hadoop.hbase.TestZooKeeper > --- > Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 600.8 s <<< > FAILURE! - in org.apache.hadoop.hbase.TestZooKeeper > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.041 s <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 600 > seconds > at org.apache.hadoop.hbase.TestZooKeeper.after(TestZooKeeper.java:103) > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.046 s <<< ERROR! > java.lang.Exception: Appears to be stuck in thread > NIOServerCxn.Factory:0.0.0.0/0.0.0.0:59935 > Not always though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347986#comment-16347986 ] Duo Zhang commented on HBASE-19904: --- [~appy] I think patch v3 is what you want? The initialization is still a bit flakey so I add some comments for WALProvider#addWALActionListener. > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v3.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19904: -- Attachment: (was: HBASE-19904-v2.patch) > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v3.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19904: -- Attachment: HBASE-19904-v3.patch > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v3.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19908) TestCoprocessorShortCircuitRPC Timeout....
[ https://issues.apache.org/jira/browse/HBASE-19908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347970#comment-16347970 ] stack commented on HBASE-19908: --- And unusual that there is a pattern as in these last three... Will try better to group them. > TestCoprocessorShortCircuitRPC Timeout > -- > > Key: HBASE-19908 > URL: https://issues.apache.org/jira/browse/HBASE-19908 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Priority: Major > Attachments: HBASE-19908.master.001.patch > > > Timedout in HBASE-19906 > Comparing a local run (16seconds total) to a timed out run up on jenkins, I > see it takes my local test 5 seconds to get the STOPPED server log line. On > jenkins in this timed out test it takes 30 seconds. Test is still running > when it is killed. Let me make it a medium test. > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/lastCompletedBuild/testReport/org.apache.hadoop.hbase.coprocessor/TestCoprocessorShortCircuitRPC/org_apache_hadoop_hbase_coprocessor_TestCoprocessorShortCircuitRPC/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[
https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347968#comment-16347968
]
Hadoop QA commented on HBASE-19904:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
10s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
1s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
5s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} hbase-server: The patch generated 0 new + 130
unchanged - 1 fixed = 130 total (was 131) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
44s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
18m 49s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 22m 14s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
56s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 61m 26s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.ipc.TestNettyRpcServer |
| | hadoop.hbase.TestClientClusterStatus |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19904 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12908706/HBASE-19904-v1.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 0ba53e755a3c 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19
15:49:21 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / e17529ba73 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/11307/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/11307/testReport/ |
| Max. process+thread count
[jira] [Commented] (HBASE-19528) Major Compaction Tool
[
https://issues.apache.org/jira/browse/HBASE-19528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347955#comment-16347955
]
Hadoop QA commented on HBASE-19528:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
33s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
35s{color} | {color:green} branch-1 passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
38s{color} | {color:green} branch-1 passed with JDK v1.7.0_171 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
19s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
55s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
15s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} branch-1 passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
37s{color} | {color:green} branch-1 passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
36s{color} | {color:green} the patch passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
40s{color} | {color:green} the patch passed with JDK v1.7.0_171 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
40s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
19s{color} | {color:red} hbase-server: The patch generated 8 new + 0 unchanged
- 0 fixed = 8 total (was 0) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
39s{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 48s{color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.5 2.7.4. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m
33s{color} | {color:red} hbase-server generated 2 new + 0 unchanged - 0 fixed =
2 total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} the patch passed with JDK v1.8.0_162 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
34s{color} | {color:green} the patch passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}196m 29s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
25s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}224m 14s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | Boxing/unboxing to parse a primitive
org.apache.hadoop.hbase.util.compaction.MajorCompactor.main(String[]) At
MajorCompactor.java:org.apache.hadoop.hbase.util.compaction.MajorCompactor.main(String[])
At MajorCompactor.java:[line 348] |
| | Possible
[jira] [Commented] (HBASE-19703) Functionality added as part of HBASE-12583 is not working after moving the split code to master
[
https://issues.apache.org/jira/browse/HBASE-19703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347947#comment-16347947
]
Chia-Ping Tsai commented on HBASE-19703:
bq. Which method?
skipStoreFileRangeCheck
> Functionality added as part of HBASE-12583 is not working after moving the
> split code to master
> ---
>
> Key: HBASE-19703
> URL: https://issues.apache.org/jira/browse/HBASE-19703
> Project: HBase
> Issue Type: Bug
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19703-WIP.patch, HBASE-19703_v2.patch,
> HBASE-19703_v3.patch, HBASE-19703_v4.patch, HBASE-19703_v5.patch
>
>
> As part of HBASE-12583 we are passing split policy to
> HRegionFileSystem#splitStoreFile so that we can allow to create reference
> files even the split key is out of HFile key range. This is needed for Local
> Indexing implementation in Phoenix. But now after moving the split code to
> master just passing null for split policy.
> {noformat}
> final String familyName = Bytes.toString(family);
> final Path path_first =
> regionFs.splitStoreFile(this.daughter_1_RI, familyName, sf, splitRow,
> false, null);
> final Path path_second =
> regionFs.splitStoreFile(this.daughter_2_RI, familyName, sf, splitRow,
> true, null);
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347946#comment-16347946 ] Duo Zhang commented on HBASE-19904: --- Oh, the WAL itself is lazy initialized. Let me try again. > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v2.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347944#comment-16347944 ] Duo Zhang commented on HBASE-19904: --- Upload a v2 patch, move listener functions to ReplicationSourceManager as [~appy] suggested. Introduce a ReplicationHelper to place the common static methods. > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v2.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19904: -- Attachment: (was: HBASE-19904-v1.patch) > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v2.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19904: -- Attachment: HBASE-19904-v2.patch > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v2.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347932#comment-16347932 ] Duo Zhang commented on HBASE-19904: --- Upload a v1 patch, add a getWALFileLengthProvider method in WALProvider. > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v1.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19904: -- Attachment: (was: HBASE-19904.patch) > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v1.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19904: -- Attachment: HBASE-19904-v1.patch > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904-v1.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19703) Functionality added as part of HBASE-12583 is not working after moving the split code to master
[
https://issues.apache.org/jira/browse/HBASE-19703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347930#comment-16347930
]
Anoop Sam John commented on HBASE-19703:
bq.The method, now, have a obscure limit that no region can be referenced
Which method?
> Functionality added as part of HBASE-12583 is not working after moving the
> split code to master
> ---
>
> Key: HBASE-19703
> URL: https://issues.apache.org/jira/browse/HBASE-19703
> Project: HBase
> Issue Type: Bug
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Major
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19703-WIP.patch, HBASE-19703_v2.patch,
> HBASE-19703_v3.patch, HBASE-19703_v4.patch, HBASE-19703_v5.patch
>
>
> As part of HBASE-12583 we are passing split policy to
> HRegionFileSystem#splitStoreFile so that we can allow to create reference
> files even the split key is out of HFile key range. This is needed for Local
> Indexing implementation in Phoenix. But now after moving the split code to
> master just passing null for split policy.
> {noformat}
> final String familyName = Bytes.toString(family);
> final Path path_first =
> regionFs.splitStoreFile(this.daughter_1_RI, familyName, sf, splitRow,
> false, null);
> final Path path_second =
> regionFs.splitStoreFile(this.daughter_2_RI, familyName, sf, splitRow,
> true, null);
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19908) TestCoprocessorShortCircuitRPC Timeout....
[ https://issues.apache.org/jira/browse/HBASE-19908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347929#comment-16347929 ] Duo Zhang commented on HBASE-19908: --- The problem is that we can not find them at once... > TestCoprocessorShortCircuitRPC Timeout > -- > > Key: HBASE-19908 > URL: https://issues.apache.org/jira/browse/HBASE-19908 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Priority: Major > Attachments: HBASE-19908.master.001.patch > > > Timedout in HBASE-19906 > Comparing a local run (16seconds total) to a timed out run up on jenkins, I > see it takes my local test 5 seconds to get the STOPPED server log line. On > jenkins in this timed out test it takes 30 seconds. Test is still running > when it is killed. Let me make it a medium test. > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/lastCompletedBuild/testReport/org.apache.hadoop.hbase.coprocessor/TestCoprocessorShortCircuitRPC/org_apache_hadoop_hbase_coprocessor_TestCoprocessorShortCircuitRPC/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347923#comment-16347923 ] Duo Zhang commented on HBASE-19904: --- Oh, not good... We need the listener when creating the actual WAL, since we will roll a wal file soon and the listeners will be notified immediately... This will be a huge change then, not easy to be done. I think the patch here at least can reduce the confusing? What do you think [~appy]? Thanks. > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19528) Major Compaction Tool
[ https://issues.apache.org/jira/browse/HBASE-19528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347917#comment-16347917 ] Hudson commented on HBASE-19528: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4505 (See [https://builds.apache.org/job/HBase-Trunk_matrix/4505/]) HBASE-19528 Major Compaction Tool; ADDENDUM (stack: rev 60827fc1ea93ce3c93ea9b86e618e419babed42f) * (delete) hbase-server/src/test/java/org/apache/hadoop/hbase/util/compaction/MajorCompactorTest.java * (delete) hbase-server/src/test/java/org/apache/hadoop/hbase/util/compaction/MajorCompactionRequestTest.java * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/util/compaction/TestMajorCompactor.java * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/util/compaction/TestMajorCompactionRequest.java > Major Compaction Tool > -- > > Key: HBASE-19528 > URL: https://issues.apache.org/jira/browse/HBASE-19528 > Project: HBase > Issue Type: New Feature >Reporter: churro morales >Assignee: churro morales >Priority: Major > Fix For: 3.0.0, 2.0.0-beta-2 > > Attachments: 0001-HBASE-19528-Major-Compaction-Tool-ADDENDUM.patch, > HBASE-19528.branch-1.patch, HBASE-19528.patch, HBASE-19528.v1.branch-1.patch, > HBASE-19528.v1.patch, HBASE-19528.v8.patch > > > The basic overview of how this tool works is: > Parameters: > Table > Stores > ClusterConcurrency > Timestamp > So you input a table, desired concurrency and the list of stores you wish to > major compact. The tool first checks the filesystem to see which stores need > compaction based on the timestamp you provide (default is current time). It > takes that list of stores that require compaction and executes those requests > concurrently with at most N distinct RegionServers compacting at a given > time. Each thread waits for the compaction to complete before moving to the > next queue. If a region split, merge or move happens this tool ensures those > regions get major compacted as well. > This helps us in two ways, we can limit how much I/O bandwidth we are using > for major compaction cluster wide and we are guaranteed after the tool > completes that all requested compactions complete regardless of moves, merges > and splits. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19907) TestMetaWithReplicas still flakey
[ https://issues.apache.org/jira/browse/HBASE-19907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347918#comment-16347918 ] Hudson commented on HBASE-19907: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4505 (See [https://builds.apache.org/job/HBase-Trunk_matrix/4505/]) HBASE-19907 TestMetaWithReplicas still flakey (stack: rev 414b2d0889f511089ad575a9c96814a95b5e8797) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestMetaWithReplicas.java > TestMetaWithReplicas still flakey > - > > Key: HBASE-19907 > URL: https://issues.apache.org/jira/browse/HBASE-19907 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19907.master.001.patch > > > Still fails because all meta replicas arrive at same server even though > supposedly protection against this added by me in HBASE-19840. > --- > Test set: org.apache.hadoop.hbase.client.TestMetaWithReplicas > --- > Tests run: 5, Failures: 0, Errors: 2, Skipped: 1, Time elapsed: 600.251 s <<< > FAILURE! - in org.apache.hadoop.hbase.client.TestMetaWithReplicas > org.apache.hadoop.hbase.client.TestMetaWithReplicas Time elapsed: 563.656 s > <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 600 > seconds > at > org.apache.hadoop.hbase.client.TestMetaWithReplicas.shutdownMetaAndDoValidations(TestMetaWithReplicas.java:255) > at > org.apache.hadoop.hbase.client.TestMetaWithReplicas.testShutdownHandling(TestMetaWithReplicas.java:181) > org.apache.hadoop.hbase.client.TestMetaWithReplicas Time elapsed: 563.656 s > <<< ERROR! > java.lang.Exception: Appears to be stuck in thread > NIOServerCxn.Factory:0.0.0.0/0.0.0.0:49912 > The move of hbase:meta actually moves it back to same server no good. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19839) Flakey TestMergeTableRegionsProcedure & TestSplitTableRegionProcedure
[ https://issues.apache.org/jira/browse/HBASE-19839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19839: -- Attachment: hbase-19839.master.004.patch > Flakey TestMergeTableRegionsProcedure & TestSplitTableRegionProcedure > - > > Key: HBASE-19839 > URL: https://issues.apache.org/jira/browse/HBASE-19839 > Project: HBase > Issue Type: Sub-task > Components: flakey, test >Reporter: stack >Assignee: Umesh Agashe >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: 0hbase-19839.master.004.patch, > 0hbase-19839.master.004.patch, 0hbase-19839.master.004.patch, > 0hbase-19839.master.004.patch, hbase-19839.master.001.patch, > hbase-19839.master.002.patch, hbase-19839.master.003.patch, > hbase-19839.master.003.patch, hbase-19839.master.003.patch, > hbase-19839.master.004.patch, hbase-19839.master.004.patch, > hbase-19839.master.004.patch, hbase-19839.master.004.patch > > > Failing about 10% of the time: > [https://builds.apache.org/job/HBASE-Flaky-Tests-branch2.0/590/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.master.assignment.TestMergeTableRegionsProcedure.txt] > Its a good one. Probably an issue down deep. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19839) Flakey TestMergeTableRegionsProcedure & TestSplitTableRegionProcedure
[ https://issues.apache.org/jira/browse/HBASE-19839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347915#comment-16347915 ] stack commented on HBASE-19839: --- proclimit of 8000 (which is probably useless) seems to work. The two test failures above should be fixed now. Retrying. > Flakey TestMergeTableRegionsProcedure & TestSplitTableRegionProcedure > - > > Key: HBASE-19839 > URL: https://issues.apache.org/jira/browse/HBASE-19839 > Project: HBase > Issue Type: Sub-task > Components: flakey, test >Reporter: stack >Assignee: Umesh Agashe >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: 0hbase-19839.master.004.patch, > 0hbase-19839.master.004.patch, 0hbase-19839.master.004.patch, > 0hbase-19839.master.004.patch, hbase-19839.master.001.patch, > hbase-19839.master.002.patch, hbase-19839.master.003.patch, > hbase-19839.master.003.patch, hbase-19839.master.003.patch, > hbase-19839.master.004.patch, hbase-19839.master.004.patch, > hbase-19839.master.004.patch, hbase-19839.master.004.patch > > > Failing about 10% of the time: > [https://builds.apache.org/job/HBASE-Flaky-Tests-branch2.0/590/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.master.assignment.TestMergeTableRegionsProcedure.txt] > Its a good one. Probably an issue down deep. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19839) Flakey TestMergeTableRegionsProcedure & TestSplitTableRegionProcedure
[ https://issues.apache.org/jira/browse/HBASE-19839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19839: -- Attachment: 0hbase-19839.master.004.patch > Flakey TestMergeTableRegionsProcedure & TestSplitTableRegionProcedure > - > > Key: HBASE-19839 > URL: https://issues.apache.org/jira/browse/HBASE-19839 > Project: HBase > Issue Type: Sub-task > Components: flakey, test >Reporter: stack >Assignee: Umesh Agashe >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: 0hbase-19839.master.004.patch, > 0hbase-19839.master.004.patch, 0hbase-19839.master.004.patch, > 0hbase-19839.master.004.patch, hbase-19839.master.001.patch, > hbase-19839.master.002.patch, hbase-19839.master.003.patch, > hbase-19839.master.003.patch, hbase-19839.master.003.patch, > hbase-19839.master.004.patch, hbase-19839.master.004.patch, > hbase-19839.master.004.patch > > > Failing about 10% of the time: > [https://builds.apache.org/job/HBASE-Flaky-Tests-branch2.0/590/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.master.assignment.TestMergeTableRegionsProcedure.txt] > Its a good one. Probably an issue down deep. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19910) TestBucketCache TimesOut
[ https://issues.apache.org/jira/browse/HBASE-19910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347914#comment-16347914 ] stack commented on HBASE-19910: --- What I pushed on branch-2 and master, changing test from small to medium. Leaving issue open to see if this fixes the test. > TestBucketCache TimesOut > > > Key: HBASE-19910 > URL: https://issues.apache.org/jira/browse/HBASE-19910 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Priority: Major > Attachments: 0001-HBASE-19910-TestBucketCache-TimesOut.patch > > > See > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11303/testReport/org.apache.hadoop.hbase.master.balancer/TestRegionLocationFinder/org_apache_hadoop_hbase_master_balancer_TestRegionLocationFinder/ > This is small test. Runs fast locally. 8 tests. Each is a second or two. Odd > though up on jenkins is that in the middle of one, there is a 19 second > pause. See here: > 2018-02-01 00:56:30,013 INFO [Time-limited test] util.ByteBufferArray(70): > Allocating buffers total=32 MB, sizePerBuffer=2 MB, count=16 > 2018-02-01 00:56:49,678 INFO [Time-limited test] bucket.BucketCache(279): > Instantiating BucketCache with acceptableFactor: 0.95, minFactor: 0.85, > extraFreeFactor: 0.1, singleFactor: 0.25, multiFactor: 0.5, memoryFactor: 0.25 > Here is full test run: > 2018-02-01 00:56:29,981 INFO [Time-limited test] hbase.ResourceChecker(148): > before: io.hfile.bucket.TestBucketCache#testInvalidCacheSplitFactorConfig[1: > blockSize=16,384, bucketSizes=[I@20322d26] Thread=77, OpenFileDescriptor=263, > MaxFileDescriptor=1048576, SystemLoadAverage=2127, ProcessCount=9, > AvailableMemoryMB=7801 > 2018-02-01 00:56:30,013 INFO [Time-limited test] util.ByteBufferArray(70): > Allocating buffers total=32 MB, sizePerBuffer=2 MB, count=16 > 2018-02-01 00:56:49,678 INFO [Time-limited test] bucket.BucketCache(279): > Instantiating BucketCache with acceptableFactor: 0.95, minFactor: 0.85, > extraFreeFactor: 0.1, singleFactor: 0.25, multiFactor: 0.5, memoryFactor: 0.25 > 2018-02-01 00:56:49,689 INFO [Time-limited test] > bucket.BucketAllocator(334): Cache totalSize=33288192, buckets=63, bucket > capacity=528384=(4*132096)=(FEWEST_ITEMS_IN_BUCKET*(largest configured > bucketcache size)) > 2018-02-01 00:56:49,690 INFO [Time-limited test] bucket.BucketCache(322): > Started bucket cache; ioengine=offheap, capacity=32 MB, blockSize=16 KB, > writerThreadNum=3, writerQLen=64, persistencePath=null, > bucketAllocator=org.apache.hadoop.hbase.io.hfile.bucket.BucketAllocator > 2018-02-01 00:56:50,020 INFO [Time-limited test] util.ByteBufferArray(70): > Allocating buffers total=32 MB, sizePerBuffer=2 MB, count=16 > 2018-02-01 00:56:50,080 ERROR [Time-limited test] util.ByteBufferArray(101): > Buffer creation interrupted > java.lang.InterruptedException > at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:404) > at java.util.concurrent.FutureTask.get(FutureTask.java:191) > at > org.apache.hadoop.hbase.util.ByteBufferArray.createBuffers(ByteBufferArray.java:96) > at > org.apache.hadoop.hbase.util.ByteBufferArray.(ByteBufferArray.java:74) > at > org.apache.hadoop.hbase.io.hfile.bucket.ByteBufferIOEngine.(ByteBufferIOEngine.java:86) > at > org.apache.hadoop.hbase.io.hfile.bucket.BucketCache.getIOEngineFromName(BucketCache.java:384) > at > org.apache.hadoop.hbase.io.hfile.bucket.BucketCache.(BucketCache.java:262) > at > org.apache.hadoop.hbase.io.hfile.bucket.TestBucketCache.checkConfigValues(TestBucketCache.java:387) > at > org.apache.hadoop.hbase.io.hfile.bucket.TestBucketCache.testInvalidCacheSplitFactorConfig(TestBucketCache.java:377) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at >
[jira] [Updated] (HBASE-19910) TestBucketCache TimesOut
[ https://issues.apache.org/jira/browse/HBASE-19910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19910: -- Attachment: 0001-HBASE-19910-TestBucketCache-TimesOut.patch > TestBucketCache TimesOut > > > Key: HBASE-19910 > URL: https://issues.apache.org/jira/browse/HBASE-19910 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Priority: Major > Attachments: 0001-HBASE-19910-TestBucketCache-TimesOut.patch > > > See > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11303/testReport/org.apache.hadoop.hbase.master.balancer/TestRegionLocationFinder/org_apache_hadoop_hbase_master_balancer_TestRegionLocationFinder/ > This is small test. Runs fast locally. 8 tests. Each is a second or two. Odd > though up on jenkins is that in the middle of one, there is a 19 second > pause. See here: > 2018-02-01 00:56:30,013 INFO [Time-limited test] util.ByteBufferArray(70): > Allocating buffers total=32 MB, sizePerBuffer=2 MB, count=16 > 2018-02-01 00:56:49,678 INFO [Time-limited test] bucket.BucketCache(279): > Instantiating BucketCache with acceptableFactor: 0.95, minFactor: 0.85, > extraFreeFactor: 0.1, singleFactor: 0.25, multiFactor: 0.5, memoryFactor: 0.25 > Here is full test run: > 2018-02-01 00:56:29,981 INFO [Time-limited test] hbase.ResourceChecker(148): > before: io.hfile.bucket.TestBucketCache#testInvalidCacheSplitFactorConfig[1: > blockSize=16,384, bucketSizes=[I@20322d26] Thread=77, OpenFileDescriptor=263, > MaxFileDescriptor=1048576, SystemLoadAverage=2127, ProcessCount=9, > AvailableMemoryMB=7801 > 2018-02-01 00:56:30,013 INFO [Time-limited test] util.ByteBufferArray(70): > Allocating buffers total=32 MB, sizePerBuffer=2 MB, count=16 > 2018-02-01 00:56:49,678 INFO [Time-limited test] bucket.BucketCache(279): > Instantiating BucketCache with acceptableFactor: 0.95, minFactor: 0.85, > extraFreeFactor: 0.1, singleFactor: 0.25, multiFactor: 0.5, memoryFactor: 0.25 > 2018-02-01 00:56:49,689 INFO [Time-limited test] > bucket.BucketAllocator(334): Cache totalSize=33288192, buckets=63, bucket > capacity=528384=(4*132096)=(FEWEST_ITEMS_IN_BUCKET*(largest configured > bucketcache size)) > 2018-02-01 00:56:49,690 INFO [Time-limited test] bucket.BucketCache(322): > Started bucket cache; ioengine=offheap, capacity=32 MB, blockSize=16 KB, > writerThreadNum=3, writerQLen=64, persistencePath=null, > bucketAllocator=org.apache.hadoop.hbase.io.hfile.bucket.BucketAllocator > 2018-02-01 00:56:50,020 INFO [Time-limited test] util.ByteBufferArray(70): > Allocating buffers total=32 MB, sizePerBuffer=2 MB, count=16 > 2018-02-01 00:56:50,080 ERROR [Time-limited test] util.ByteBufferArray(101): > Buffer creation interrupted > java.lang.InterruptedException > at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:404) > at java.util.concurrent.FutureTask.get(FutureTask.java:191) > at > org.apache.hadoop.hbase.util.ByteBufferArray.createBuffers(ByteBufferArray.java:96) > at > org.apache.hadoop.hbase.util.ByteBufferArray.(ByteBufferArray.java:74) > at > org.apache.hadoop.hbase.io.hfile.bucket.ByteBufferIOEngine.(ByteBufferIOEngine.java:86) > at > org.apache.hadoop.hbase.io.hfile.bucket.BucketCache.getIOEngineFromName(BucketCache.java:384) > at > org.apache.hadoop.hbase.io.hfile.bucket.BucketCache.(BucketCache.java:262) > at > org.apache.hadoop.hbase.io.hfile.bucket.TestBucketCache.checkConfigValues(TestBucketCache.java:387) > at > org.apache.hadoop.hbase.io.hfile.bucket.TestBucketCache.testInvalidCacheSplitFactorConfig(TestBucketCache.java:377) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at
[jira] [Created] (HBASE-19910) TestBucketCache TimesOut
stack created HBASE-19910: - Summary: TestBucketCache TimesOut Key: HBASE-19910 URL: https://issues.apache.org/jira/browse/HBASE-19910 Project: HBase Issue Type: Sub-task Reporter: stack See https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11303/testReport/org.apache.hadoop.hbase.master.balancer/TestRegionLocationFinder/org_apache_hadoop_hbase_master_balancer_TestRegionLocationFinder/ This is small test. Runs fast locally. 8 tests. Each is a second or two. Odd though up on jenkins is that in the middle of one, there is a 19 second pause. See here: 2018-02-01 00:56:30,013 INFO [Time-limited test] util.ByteBufferArray(70): Allocating buffers total=32 MB, sizePerBuffer=2 MB, count=16 2018-02-01 00:56:49,678 INFO [Time-limited test] bucket.BucketCache(279): Instantiating BucketCache with acceptableFactor: 0.95, minFactor: 0.85, extraFreeFactor: 0.1, singleFactor: 0.25, multiFactor: 0.5, memoryFactor: 0.25 Here is full test run: 2018-02-01 00:56:29,981 INFO [Time-limited test] hbase.ResourceChecker(148): before: io.hfile.bucket.TestBucketCache#testInvalidCacheSplitFactorConfig[1: blockSize=16,384, bucketSizes=[I@20322d26] Thread=77, OpenFileDescriptor=263, MaxFileDescriptor=1048576, SystemLoadAverage=2127, ProcessCount=9, AvailableMemoryMB=7801 2018-02-01 00:56:30,013 INFO [Time-limited test] util.ByteBufferArray(70): Allocating buffers total=32 MB, sizePerBuffer=2 MB, count=16 2018-02-01 00:56:49,678 INFO [Time-limited test] bucket.BucketCache(279): Instantiating BucketCache with acceptableFactor: 0.95, minFactor: 0.85, extraFreeFactor: 0.1, singleFactor: 0.25, multiFactor: 0.5, memoryFactor: 0.25 2018-02-01 00:56:49,689 INFO [Time-limited test] bucket.BucketAllocator(334): Cache totalSize=33288192, buckets=63, bucket capacity=528384=(4*132096)=(FEWEST_ITEMS_IN_BUCKET*(largest configured bucketcache size)) 2018-02-01 00:56:49,690 INFO [Time-limited test] bucket.BucketCache(322): Started bucket cache; ioengine=offheap, capacity=32 MB, blockSize=16 KB, writerThreadNum=3, writerQLen=64, persistencePath=null, bucketAllocator=org.apache.hadoop.hbase.io.hfile.bucket.BucketAllocator 2018-02-01 00:56:50,020 INFO [Time-limited test] util.ByteBufferArray(70): Allocating buffers total=32 MB, sizePerBuffer=2 MB, count=16 2018-02-01 00:56:50,080 ERROR [Time-limited test] util.ByteBufferArray(101): Buffer creation interrupted java.lang.InterruptedException at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:404) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.apache.hadoop.hbase.util.ByteBufferArray.createBuffers(ByteBufferArray.java:96) at org.apache.hadoop.hbase.util.ByteBufferArray.(ByteBufferArray.java:74) at org.apache.hadoop.hbase.io.hfile.bucket.ByteBufferIOEngine.(ByteBufferIOEngine.java:86) at org.apache.hadoop.hbase.io.hfile.bucket.BucketCache.getIOEngineFromName(BucketCache.java:384) at org.apache.hadoop.hbase.io.hfile.bucket.BucketCache.(BucketCache.java:262) at org.apache.hadoop.hbase.io.hfile.bucket.TestBucketCache.checkConfigValues(TestBucketCache.java:387) at org.apache.hadoop.hbase.io.hfile.bucket.TestBucketCache.testInvalidCacheSplitFactorConfig(TestBucketCache.java:377) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
[jira] [Commented] (HBASE-19908) TestCoprocessorShortCircuitRPC Timeout....
[ https://issues.apache.org/jira/browse/HBASE-19908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347898#comment-16347898 ] Appy commented on HBASE-19908: -- Let's use HBASE-19878 directly for making these minor changes? Otherwise there's all this process of linking everything together - new jiras, HBASE-19878 and HBASE-19147 fyi [~Apache9]. > TestCoprocessorShortCircuitRPC Timeout > -- > > Key: HBASE-19908 > URL: https://issues.apache.org/jira/browse/HBASE-19908 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Priority: Major > Attachments: HBASE-19908.master.001.patch > > > Timedout in HBASE-19906 > Comparing a local run (16seconds total) to a timed out run up on jenkins, I > see it takes my local test 5 seconds to get the STOPPED server log line. On > jenkins in this timed out test it takes 30 seconds. Test is still running > when it is killed. Let me make it a medium test. > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/lastCompletedBuild/testReport/org.apache.hadoop.hbase.coprocessor/TestCoprocessorShortCircuitRPC/org_apache_hadoop_hbase_coprocessor_TestCoprocessorShortCircuitRPC/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19879) Promote TestAcidGuaranteesXXX to LargeTests
[ https://issues.apache.org/jira/browse/HBASE-19879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347897#comment-16347897 ] Appy commented on HBASE-19879: -- Good one > Promote TestAcidGuaranteesXXX to LargeTests > --- > > Key: HBASE-19879 > URL: https://issues.apache.org/jira/browse/HBASE-19879 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19879.patch > > > They spent about 170s on my local machine and the time limit for MediumTests > is 180s, so declare it as MediumTests is not safe. And in the comments, > MediumTests is supposed to run 50 seconds. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19908) TestCoprocessorShortCircuitRPC Timeout....
[ https://issues.apache.org/jira/browse/HBASE-19908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-19908: - Issue Type: Sub-task (was: Bug) Parent: HBASE-19147 > TestCoprocessorShortCircuitRPC Timeout > -- > > Key: HBASE-19908 > URL: https://issues.apache.org/jira/browse/HBASE-19908 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Priority: Major > Attachments: HBASE-19908.master.001.patch > > > Timedout in HBASE-19906 > Comparing a local run (16seconds total) to a timed out run up on jenkins, I > see it takes my local test 5 seconds to get the STOPPED server log line. On > jenkins in this timed out test it takes 30 seconds. Test is still running > when it is killed. Let me make it a medium test. > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/lastCompletedBuild/testReport/org.apache.hadoop.hbase.coprocessor/TestCoprocessorShortCircuitRPC/org_apache_hadoop_hbase_coprocessor_TestCoprocessorShortCircuitRPC/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347893#comment-16347893 ] Duo Zhang commented on HBASE-19904: --- Seems fine. We can do everything inside the Replication#initialize, even for setting the PeerInfoProvider for synchronous replication. Let me provide a patch. Thanks. > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19908) TestCoprocessorShortCircuitRPC Timeout....
[ https://issues.apache.org/jira/browse/HBASE-19908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-19908: - Issue Type: Bug (was: Sub-task) Parent: (was: HBASE-19147) > TestCoprocessorShortCircuitRPC Timeout > -- > > Key: HBASE-19908 > URL: https://issues.apache.org/jira/browse/HBASE-19908 > Project: HBase > Issue Type: Bug >Reporter: stack >Priority: Major > Attachments: HBASE-19908.master.001.patch > > > Timedout in HBASE-19906 > Comparing a local run (16seconds total) to a timed out run up on jenkins, I > see it takes my local test 5 seconds to get the STOPPED server log line. On > jenkins in this timed out test it takes 30 seconds. Test is still running > when it is killed. Let me make it a medium test. > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/lastCompletedBuild/testReport/org.apache.hadoop.hbase.coprocessor/TestCoprocessorShortCircuitRPC/org_apache_hadoop_hbase_coprocessor_TestCoprocessorShortCircuitRPC/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19909) TestRegionLocationFinder Timeout
[ https://issues.apache.org/jira/browse/HBASE-19909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347885#comment-16347885 ] stack commented on HBASE-19909: --- 2.001 is what I pushed to master and branch-2. Lets see if this fixes it. > TestRegionLocationFinder Timeout > > > Key: HBASE-19909 > URL: https://issues.apache.org/jira/browse/HBASE-19909 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19909.branch-2.001.patch > > > This test is timing out a bunch in runs since we moved over to the nice new > fancy, smancy, timeout thingymajig. > Similar to HBASE-19908, I see that on Jenkins, the test is making progress > but is running at a slower rate. > This is a 'smalltest' that starts a minicluster with 5 servers creating a > table with 26 odd regions. > On my uncontested machine, it takes 20 seconds to complete the create table. > On jenkins it takes 29 seconds (see > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11303/testReport/org.apache.hadoop.hbase.master.balancer/TestRegionLocationFinder/org_apache_hadoop_hbase_master_balancer_TestRegionLocationFinder/) > Small tests are supposed to complete inside 30 seconds. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347886#comment-16347886 ] Duo Zhang commented on HBASE-19904: --- Anyway, let me try your solution to see if it works. At least I agree that WALFactory should not implement WALFileLengthProvider, it is strange. > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19909) TestRegionLocationFinder Timeout
[ https://issues.apache.org/jira/browse/HBASE-19909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19909: -- Attachment: HBASE-19909.branch-2.001.patch > TestRegionLocationFinder Timeout > > > Key: HBASE-19909 > URL: https://issues.apache.org/jira/browse/HBASE-19909 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19909.branch-2.001.patch > > > This test is timing out a bunch in runs since we moved over to the nice new > fancy, smancy, timeout thingymajig. > Similar to HBASE-19908, I see that on Jenkins, the test is making progress > but is running at a slower rate. > This is a 'smalltest' that starts a minicluster with 5 servers creating a > table with 26 odd regions. > On my uncontested machine, it takes 20 seconds to complete the create table. > On jenkins it takes 29 seconds (see > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11303/testReport/org.apache.hadoop.hbase.master.balancer/TestRegionLocationFinder/org_apache_hadoop_hbase_master_balancer_TestRegionLocationFinder/) > Small tests are supposed to complete inside 30 seconds. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-19908) TestCoprocessorShortCircuitRPC Timeout....
[ https://issues.apache.org/jira/browse/HBASE-19908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347866#comment-16347866 ] stack edited comment on HBASE-19908 at 2/1/18 1:52 AM: --- .001 is what I pushed to master and branch-2. Leaving open to see if this fixes it. It makes the test medium rather than small was (Author: stack): .001 is what I pushed to master and branch-2. Leaving open to see if this fixes it. > TestCoprocessorShortCircuitRPC Timeout > -- > > Key: HBASE-19908 > URL: https://issues.apache.org/jira/browse/HBASE-19908 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Priority: Major > Attachments: HBASE-19908.master.001.patch > > > Timedout in HBASE-19906 > Comparing a local run (16seconds total) to a timed out run up on jenkins, I > see it takes my local test 5 seconds to get the STOPPED server log line. On > jenkins in this timed out test it takes 30 seconds. Test is still running > when it is killed. Let me make it a medium test. > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/lastCompletedBuild/testReport/org.apache.hadoop.hbase.coprocessor/TestCoprocessorShortCircuitRPC/org_apache_hadoop_hbase_coprocessor_TestCoprocessorShortCircuitRPC/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-19909) TestRegionLocationFinder Timeout
stack created HBASE-19909: - Summary: TestRegionLocationFinder Timeout Key: HBASE-19909 URL: https://issues.apache.org/jira/browse/HBASE-19909 Project: HBase Issue Type: Sub-task Reporter: stack Assignee: stack Fix For: 2.0.0-beta-2 This test is timing out a bunch in runs since we moved over to the nice new fancy, smancy, timeout thingymajig. Similar to HBASE-19908, I see that on Jenkins, the test is making progress but is running at a slower rate. This is a 'smalltest' that starts a minicluster with 5 servers creating a table with 26 odd regions. On my uncontested machine, it takes 20 seconds to complete the create table. On jenkins it takes 29 seconds (see https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/11303/testReport/org.apache.hadoop.hbase.master.balancer/TestRegionLocationFinder/org_apache_hadoop_hbase_master_balancer_TestRegionLocationFinder/) Small tests are supposed to complete inside 30 seconds. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347880#comment-16347880 ] Duo Zhang commented on HBASE-19904: --- And if you want a clean solution, it will be huge, which I do not intend to do even in 3.0... The current WALActionListener is based on FileSystem, while the WAL is not. And then Replication is also based on FileSystem, more or less. We need to find a better way to abstract the interface so that we can remove the FileSystem dependency at high level. IIRC there is a issue for this. Thanks. > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[
https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347871#comment-16347871
]
Duo Zhang commented on HBASE-19904:
---
{quote}
Also, since this is not a bug fix, this should not go in 2.0-beta.
{quote}
Disagree. At least there is a TODO in the code.
> Find a better way to deal with the cyclic dependency when initializing WAL
> and Replication
> --
>
> Key: HBASE-19904
> URL: https://issues.apache.org/jira/browse/HBASE-19904
> Project: HBase
> Issue Type: Improvement
> Components: Replication, wal
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19904.patch
>
>
> When implementing synchronous replication, I found that we need to depend
> more on replication in WAL so it is even more pain...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[
https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347869#comment-16347869
]
Duo Zhang commented on HBASE-19904:
---
{quote}
At system level, there's very clear strong dependency of replication on wal,
there's no way we should make wal depend on replication.
{quote}
No. At least, before I introduce WALFileLengthProvider, replication does not
depend on WAL, they just communicate with the HDFS. And after synchronous
replication, there will be strong dependency of WAL on replication, since it
needs to know whether we should write to the remote HDFS, so we must initialize
Replication before WAL.
So my solution is simple, revert back to the old implementation, initialize
Replication first, and then WAL. It is easy to understand.
Thanks.
> Find a better way to deal with the cyclic dependency when initializing WAL
> and Replication
> --
>
> Key: HBASE-19904
> URL: https://issues.apache.org/jira/browse/HBASE-19904
> Project: HBase
> Issue Type: Improvement
> Components: Replication, wal
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19904.patch
>
>
> When implementing synchronous replication, I found that we need to depend
> more on replication in WAL so it is even more pain...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[ https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347867#comment-16347867 ] Appy commented on HBASE-19904: -- Another improvement, if possible, is moving listener functions to ReplicationSourceManager. > Find a better way to deal with the cyclic dependency when initializing WAL > and Replication > -- > > Key: HBASE-19904 > URL: https://issues.apache.org/jira/browse/HBASE-19904 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19904.patch > > > When implementing synchronous replication, I found that we need to depend > more on replication in WAL so it is even more pain... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19908) TestCoprocessorShortCircuitRPC Timeout....
[ https://issues.apache.org/jira/browse/HBASE-19908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347866#comment-16347866 ] stack commented on HBASE-19908: --- .001 is what I pushed to master and branch-2. Leaving open to see if this fixes it. > TestCoprocessorShortCircuitRPC Timeout > -- > > Key: HBASE-19908 > URL: https://issues.apache.org/jira/browse/HBASE-19908 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Priority: Major > Attachments: HBASE-19908.master.001.patch > > > Timedout in HBASE-19906 > Comparing a local run (16seconds total) to a timed out run up on jenkins, I > see it takes my local test 5 seconds to get the STOPPED server log line. On > jenkins in this timed out test it takes 30 seconds. Test is still running > when it is killed. Let me make it a medium test. > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/lastCompletedBuild/testReport/org.apache.hadoop.hbase.coprocessor/TestCoprocessorShortCircuitRPC/org_apache_hadoop_hbase_coprocessor_TestCoprocessorShortCircuitRPC/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19908) TestCoprocessorShortCircuitRPC Timeout....
[ https://issues.apache.org/jira/browse/HBASE-19908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19908: -- Attachment: HBASE-19908.master.001.patch > TestCoprocessorShortCircuitRPC Timeout > -- > > Key: HBASE-19908 > URL: https://issues.apache.org/jira/browse/HBASE-19908 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Priority: Major > Attachments: HBASE-19908.master.001.patch > > > Timedout in HBASE-19906 > Comparing a local run (16seconds total) to a timed out run up on jenkins, I > see it takes my local test 5 seconds to get the STOPPED server log line. On > jenkins in this timed out test it takes 30 seconds. Test is still running > when it is killed. Let me make it a medium test. > https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/lastCompletedBuild/testReport/org.apache.hadoop.hbase.coprocessor/TestCoprocessorShortCircuitRPC/org_apache_hadoop_hbase_coprocessor_TestCoprocessorShortCircuitRPC/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19904) Find a better way to deal with the cyclic dependency when initializing WAL and Replication
[
https://issues.apache.org/jira/browse/HBASE-19904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347864#comment-16347864
]
Appy commented on HBASE-19904:
--
{noformat}
-// There is a cyclic dependency between ReplicationSourceHandler and
WALFactory.
-// We use WALActionsListener to get the newly rolled WALs, so we need to
get the
-// WALActionsListeners from ReplicationSourceHandler before constructing
WALFactory. And then
-// ReplicationSourceHandler need to use WALFactory get the length of the
wal file being written.
-// So we here we need to construct WALFactory first, and then pass it to
the initialized method
-// of ReplicationSourceHandler.
{noformat}
Is this the core issue you are trying to solve?
Reading that comment...it's real bad code smell.
At system level, there's very clear strong dependency of replication on wal,
there's no way we should make wal depend on replication.
It exists right now and is very bad, we should try to get rid of it instead of
adding more scaffolding to support it.
Suggestion:
{code:java}
interface WALProvider {
...
// General observer/listener patterns allow adding/removing observer on the
fly. We just need adding, so let's add this.
void addWALActionsListener(WALActionsListener listener);
// This is right because currently WALFactory does
provider.getWAL().stream()., no need of that indirection.
WALFileLengthProvider getWALFileLengthProvider(); // Can be done via
inheritance too, but let's use composition.
...
}
{code}
In HRegionServer#setupWALAndReplication
{code:java}
private void setupWALAndReplication() throws IOException {
.
// WALFactory has no need to know about listeners, only WALProvider does.
this.walFactory = new WALFactory(conf, serverName.toString());
// No need of List listeners and related logic.
walFactory.getWALProvider().addWALActionsListener(new MetricsWAL()); // Meta
wal provider takes care of itself, so need for it.
createNewReplicationInstance(conf, this, this.walFs, logDir, oldLogDir);
//btw, we are not even using the last 3 params in the function.
if (this.replicationSourceHandler != null) {
this.replicationSourceHandler.initialize(this, walFs, logDir, oldLogDir,
factory);
}
.
}
{code}
In Replication#initialize
{code:java}
// Changed type of last param to WALProvider
public void initialize(Server server, FileSystem fs, Path logDir, Path
oldLogDir, WALProvider walProvider) throws IOException {
this.replicationManager = new ReplicationSourceManager(,
walProvider.getWALFileLengthProvider());
walProvider.addWALActionsListener(this);
}
{code}
After all this, WALFactory will not implement WALFileLengthProvider anymore.
I think this will work because Replication will be able to register itself
before anything calls WALFactory.getWAL(region).
Wtdy?
I am trying to come up with a solution considering that we'll have separate
hbase-wal and hbase-replication-implementation modules (ignoring naming for
now) in future.
I am not much familiar with Replication and WAL code, so it's possible that the
solution above is not comprehensive and may be missing/wrong on some elements,
but i certainly feel that we can have a good discussion here and come up with a
better design.
Also, since this is not a bug fix, this should not go in 2.0-beta.
[~stack] The more things we don't backport to branch-2 (since it's in 2.0
beta), the wider the gap from master becomes. Having one less branch certainly
decreases current backport work; but that also means no
improvements/maintenance stuff getting backported into 2.1, widening gap
between master and branch-2, and thus more merge conflicts in future. Please
create branch-2.0. :)
> Find a better way to deal with the cyclic dependency when initializing WAL
> and Replication
> --
>
> Key: HBASE-19904
> URL: https://issues.apache.org/jira/browse/HBASE-19904
> Project: HBase
> Issue Type: Improvement
> Components: Replication, wal
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-19904.patch
>
>
> When implementing synchronous replication, I found that we need to depend
> more on replication in WAL so it is even more pain...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-19908) TestCoprocessorShortCircuitRPC Timeout....
stack created HBASE-19908: - Summary: TestCoprocessorShortCircuitRPC Timeout Key: HBASE-19908 URL: https://issues.apache.org/jira/browse/HBASE-19908 Project: HBase Issue Type: Sub-task Reporter: stack Timedout in HBASE-19906 Comparing a local run (16seconds total) to a timed out run up on jenkins, I see it takes my local test 5 seconds to get the STOPPED server log line. On jenkins in this timed out test it takes 30 seconds. Test is still running when it is killed. Let me make it a medium test. https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/lastCompletedBuild/testReport/org.apache.hadoop.hbase.coprocessor/TestCoprocessorShortCircuitRPC/org_apache_hadoop_hbase_coprocessor_TestCoprocessorShortCircuitRPC/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19906) TestZooKeeper Timeout
[ https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347855#comment-16347855 ] Umesh Agashe commented on HBASE-19906: -- +1 latest patch lgtm > TestZooKeeper Timeout > - > > Key: HBASE-19906 > URL: https://issues.apache.org/jira/browse/HBASE-19906 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19906.branch-2.001.patch, > HBASE-19906.branch-2.002.patch, HBASE-19906.branch-2.003.patch > > > TestZooKeeper is timing out causing hbase2 failures and breaking > HBASE-Flaky-Tests-branch2.0.0. > --- > Test set: org.apache.hadoop.hbase.TestZooKeeper > --- > Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 600.8 s <<< > FAILURE! - in org.apache.hadoop.hbase.TestZooKeeper > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.041 s <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 600 > seconds > at org.apache.hadoop.hbase.TestZooKeeper.after(TestZooKeeper.java:103) > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.046 s <<< ERROR! > java.lang.Exception: Appears to be stuck in thread > NIOServerCxn.Factory:0.0.0.0/0.0.0.0:59935 > Not always though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19839) Flakey TestMergeTableRegionsProcedure & TestSplitTableRegionProcedure
[
https://issues.apache.org/jira/browse/HBASE-19839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347849#comment-16347849
]
Hadoop QA commented on HBASE-19839:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 4m
35s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 8m
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
50s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
58s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
8s{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
48s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
20m 58s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 26m 24s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
30s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 75m 44s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.io.hfile.bucket.TestBucketCache |
| | hadoop.hbase.master.balancer.TestRegionLocationFinder |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19839 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12908683/0hbase-19839.master.004.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 96ea7b0eaf96 3.13.0-135-generic #184-Ubuntu SMP Wed Oct 18
11:55:51 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 414b2d0889 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/11304/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/11304/testReport/ |
| Max. process+thread count | 720 (vs. ulimit of 8000) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/11304/console |
|
[jira] [Commented] (HBASE-19906) TestZooKeeper Timeout
[
https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347846#comment-16347846
]
Hadoop QA commented on HBASE-19906:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
14s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} branch-2 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 10m
51s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
40s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
6s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
59s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
37s{color} | {color:green} branch-2 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
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}
15m 3s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 29m 43s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
15s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 69m 37s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.master.balancer.TestRegionLocationFinder |
| | hadoop.hbase.TestCheckTestClasses |
| | hadoop.hbase.coprocessor.TestCoprocessorShortCircuitRPC |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:9f2f2db |
| JIRA Issue | HBASE-19906 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12908684/HBASE-19906.branch-2.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 6b0edc7cb613 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | branch-2 / 7a82126f8b |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/11303/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/11303/testReport/ |
|
[jira] [Updated] (HBASE-19906) TestZooKeeper Timeout
[ https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19906: -- Attachment: HBASE-19906.branch-2.003.patch > TestZooKeeper Timeout > - > > Key: HBASE-19906 > URL: https://issues.apache.org/jira/browse/HBASE-19906 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19906.branch-2.001.patch, > HBASE-19906.branch-2.002.patch, HBASE-19906.branch-2.003.patch > > > TestZooKeeper is timing out causing hbase2 failures and breaking > HBASE-Flaky-Tests-branch2.0.0. > --- > Test set: org.apache.hadoop.hbase.TestZooKeeper > --- > Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 600.8 s <<< > FAILURE! - in org.apache.hadoop.hbase.TestZooKeeper > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.041 s <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 600 > seconds > at org.apache.hadoop.hbase.TestZooKeeper.after(TestZooKeeper.java:103) > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.046 s <<< ERROR! > java.lang.Exception: Appears to be stuck in thread > NIOServerCxn.Factory:0.0.0.0/0.0.0.0:59935 > Not always though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19906) TestZooKeeper Timeout
[ https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347804#comment-16347804 ] stack commented on HBASE-19906: --- .002 addresses [~uagashe] review. > TestZooKeeper Timeout > - > > Key: HBASE-19906 > URL: https://issues.apache.org/jira/browse/HBASE-19906 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19906.branch-2.001.patch, > HBASE-19906.branch-2.002.patch > > > TestZooKeeper is timing out causing hbase2 failures and breaking > HBASE-Flaky-Tests-branch2.0.0. > --- > Test set: org.apache.hadoop.hbase.TestZooKeeper > --- > Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 600.8 s <<< > FAILURE! - in org.apache.hadoop.hbase.TestZooKeeper > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.041 s <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 600 > seconds > at org.apache.hadoop.hbase.TestZooKeeper.after(TestZooKeeper.java:103) > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.046 s <<< ERROR! > java.lang.Exception: Appears to be stuck in thread > NIOServerCxn.Factory:0.0.0.0/0.0.0.0:59935 > Not always though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19906) TestZooKeeper Timeout
[ https://issues.apache.org/jira/browse/HBASE-19906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19906: -- Attachment: HBASE-19906.branch-2.002.patch > TestZooKeeper Timeout > - > > Key: HBASE-19906 > URL: https://issues.apache.org/jira/browse/HBASE-19906 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-19906.branch-2.001.patch, > HBASE-19906.branch-2.002.patch > > > TestZooKeeper is timing out causing hbase2 failures and breaking > HBASE-Flaky-Tests-branch2.0.0. > --- > Test set: org.apache.hadoop.hbase.TestZooKeeper > --- > Tests run: 6, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 600.8 s <<< > FAILURE! - in org.apache.hadoop.hbase.TestZooKeeper > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.041 s <<< ERROR! > org.junit.runners.model.TestTimedOutException: test timed out after 600 > seconds > at org.apache.hadoop.hbase.TestZooKeeper.after(TestZooKeeper.java:103) > org.apache.hadoop.hbase.TestZooKeeper Time elapsed: 551.046 s <<< ERROR! > java.lang.Exception: Appears to be stuck in thread > NIOServerCxn.Factory:0.0.0.0/0.0.0.0:59935 > Not always though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
