[jira] [Commented] (HBASE-19204) branch-1.2 times out and is taking 6-7 hours to complete
[
https://issues.apache.org/jira/browse/HBASE-19204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16257981#comment-16257981
]
Chia-Ping Tsai commented on HBASE-19204:
It seems the hang occurs on closing the {{MiniDFSCluster}}. The test is shown
below.
{code}
@Test
public void testHdfsHang() throws Exception {
MiniDFSCluster dfsCluster = null;
for (int i = 0; i != 10; ++i) {
try {
dfsCluster = new MiniDFSCluster
.Builder(new Configuration())
.checkExitOnShutdown(true)
.numDataNodes(2)
.format(true)
.racks(null)
.build();
FileSystem fs = dfsCluster.getFileSystem();
fs.getConf().set("fs.defaultFS", new Path(fs.getUri()).toString());
dfsCluster.waitClusterUp();
} finally {
dfsCluster.shutdown();
}
}
}
{code}
The weird thing is that only openjdk-7u141 and openjdk-7u151 prompt the issue.
The older jdk7 or jdk8 don't hang. The OS I used for testing is centos-1708 and
ubuntu-14.04.
> branch-1.2 times out and is taking 6-7 hours to complete
>
>
> Key: HBASE-19204
> URL: https://issues.apache.org/jira/browse/HBASE-19204
> Project: HBase
> Issue Type: Umbrella
> Components: test
>Reporter: stack
>
> Sean has been looking at tooling and infra. This Umbrellas is about looking
> at actual tests. For example, running locally on dedicated machine I picked a
> random test, TestPerColumnFamilyFlush. In my test run, it wrote 16M lines. It
> seems to be having zk issues but it is catching interrupts and ignoring them
> ([~carp84] fixed this in later versions over in HBASE-18441).
> Let me try and do some fixup under this umbrella so we can get a 1.2.7 out
> the door.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19289) CommonFSUtils$StreamLacksCapabilityException: hflush when running test against hadoop3 beta1
[
https://issues.apache.org/jira/browse/HBASE-19289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258012#comment-16258012
]
Ted Yu commented on HBASE-19289:
Patch v1 uses approach #2.
This would allow me to run test suite against hadoop3.
> CommonFSUtils$StreamLacksCapabilityException: hflush when running test
> against hadoop3 beta1
>
>
> Key: HBASE-19289
> URL: https://issues.apache.org/jira/browse/HBASE-19289
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
> Attachments: 19289.v1.txt
>
>
> As of commit d8fb10c8329b19223c91d3cda6ef149382ad4ea0 , I encountered the
> following exception when running unit test against hadoop3 beta1:
> {code}
> testRefreshStoreFiles(org.apache.hadoop.hbase.regionserver.TestHStore) Time
> elapsed: 0.061 sec <<< ERROR!
> java.io.IOException: cannot get log writer
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.initHRegion(TestHStore.java:215)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:220)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:195)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:190)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:185)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:179)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:173)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.testRefreshStoreFiles(TestHStore.java:962)
> Caused by:
> org.apache.hadoop.hbase.util.CommonFSUtils$StreamLacksCapabilityException:
> hflush
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.initHRegion(TestHStore.java:215)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:220)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:195)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:190)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:185)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:179)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:173)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.testRefreshStoreFiles(TestHStore.java:962)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19289) CommonFSUtils$StreamLacksCapabilityException: hflush when running test against hadoop3 beta1
[
https://issues.apache.org/jira/browse/HBASE-19289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-19289:
---
Attachment: 19289.v1.txt
> CommonFSUtils$StreamLacksCapabilityException: hflush when running test
> against hadoop3 beta1
>
>
> Key: HBASE-19289
> URL: https://issues.apache.org/jira/browse/HBASE-19289
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
> Attachments: 19289.v1.txt
>
>
> As of commit d8fb10c8329b19223c91d3cda6ef149382ad4ea0 , I encountered the
> following exception when running unit test against hadoop3 beta1:
> {code}
> testRefreshStoreFiles(org.apache.hadoop.hbase.regionserver.TestHStore) Time
> elapsed: 0.061 sec <<< ERROR!
> java.io.IOException: cannot get log writer
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.initHRegion(TestHStore.java:215)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:220)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:195)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:190)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:185)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:179)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:173)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.testRefreshStoreFiles(TestHStore.java:962)
> Caused by:
> org.apache.hadoop.hbase.util.CommonFSUtils$StreamLacksCapabilityException:
> hflush
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.initHRegion(TestHStore.java:215)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:220)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:195)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:190)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:185)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:179)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.init(TestHStore.java:173)
> at
> org.apache.hadoop.hbase.regionserver.TestHStore.testRefreshStoreFiles(TestHStore.java:962)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19204) branch-1.2 times out and is taking 6-7 hours to complete
[ https://issues.apache.org/jira/browse/HBASE-19204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258010#comment-16258010 ] Duo Zhang commented on HBASE-19204: --- Maybe there is an exception being thrown in the try block then the shutdown hangs? Add a catch? Thanks. > branch-1.2 times out and is taking 6-7 hours to complete > > > Key: HBASE-19204 > URL: https://issues.apache.org/jira/browse/HBASE-19204 > Project: HBase > Issue Type: Umbrella > Components: test >Reporter: stack > > Sean has been looking at tooling and infra. This Umbrellas is about looking > at actual tests. For example, running locally on dedicated machine I picked a > random test, TestPerColumnFamilyFlush. In my test run, it wrote 16M lines. It > seems to be having zk issues but it is catching interrupts and ignoring them > ([~carp84] fixed this in later versions over in HBASE-18441). > Let me try and do some fixup under this umbrella so we can get a 1.2.7 out > the door. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19204) branch-1.2 times out and is taking 6-7 hours to complete
[ https://issues.apache.org/jira/browse/HBASE-19204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258022#comment-16258022 ] Chia-Ping Tsai commented on HBASE-19204: bq. Add a catch? Done but nothing is caught. Will hack the MiniDFSCluster to dig in. > branch-1.2 times out and is taking 6-7 hours to complete > > > Key: HBASE-19204 > URL: https://issues.apache.org/jira/browse/HBASE-19204 > Project: HBase > Issue Type: Umbrella > Components: test >Reporter: stack > > Sean has been looking at tooling and infra. This Umbrellas is about looking > at actual tests. For example, running locally on dedicated machine I picked a > random test, TestPerColumnFamilyFlush. In my test run, it wrote 16M lines. It > seems to be having zk issues but it is catching interrupts and ignoring them > ([~carp84] fixed this in later versions over in HBASE-18441). > Let me try and do some fixup under this umbrella so we can get a 1.2.7 out > the door. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19204) branch-1.2 times out and is taking 6-7 hours to complete
[
https://issues.apache.org/jira/browse/HBASE-19204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258038#comment-16258038
]
Chia-Ping Tsai commented on HBASE-19204:
It is blocked when closing {{HttpServer2}}. Zoom in on the {{HttpServer2}}
{code}
@Test
public void testHttpServerHang() throws Exception {
for (int i = 0; i != 500; ++i) {
HttpServer2 server = null;
try {
Configuration conf = new Configuration();
conf.setInt("hadoop.http.max.threads", 10);
server = createTestServer(conf);
server.addServlet("echo", "/echo", TestHttpServer.EchoServlet.class);
server.addServlet("echomap", "/echomap",
TestHttpServer.EchoMapServlet.class);
server.addServlet("htmlcontent", "/htmlcontent",
TestHttpServer.HtmlContentServlet.class);
server.addServlet("longheader", "/longheader",
TestHttpServer.LongHeaderServlet.class);
server.addJerseyResourcePackage(
JerseyResource.class.getPackage().getName(), "/jersey/*");
server.start();
} finally {
if (server != null) {
server.stop();
}
}
}
}
{code}
And then i got the following stack dump.
{quote}
"2020688994@qtp-1069352689-1 - Acceptor0
HttpServer2$SelectChannelConnectorWithSafeStartup@localhost:39279" daemon
prio=10 tid=0x7fbd8c7a4000 nid=0x1c3e waiting for monitor entry
[0x7fbd740e1000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:464)
- waiting to lock <0xec24c798> (a
org.mortbay.io.nio.SelectorManager$SelectSet)
at org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:192)
at
org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124)
at
org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:708)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
"main" prio=10 tid=0x7fbd8c009000 nid=0x1bdc runnable [0x7fbd93ad5000]
java.lang.Thread.State: RUNNABLE
at
org.mortbay.io.nio.SelectorManager$SelectSet.stop(SelectorManager.java:878)
- locked <0xec24c798> (a
org.mortbay.io.nio.SelectorManager$SelectSet)
at org.mortbay.io.nio.SelectorManager.doStop(SelectorManager.java:240)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76)
- locked <0xec07da28> (a java.lang.Object)
at
org.mortbay.jetty.nio.SelectChannelConnector.close(SelectChannelConnector.java:136)
{quote}
And then i noticed the same observation is already in the HBASE-14430 and
HBASE-14505. [~stack] Are you still look for the cryptic JVM version? :)
> branch-1.2 times out and is taking 6-7 hours to complete
>
>
> Key: HBASE-19204
> URL: https://issues.apache.org/jira/browse/HBASE-19204
> Project: HBase
> Issue Type: Umbrella
> Components: test
>Reporter: stack
>
> Sean has been looking at tooling and infra. This Umbrellas is about looking
> at actual tests. For example, running locally on dedicated machine I picked a
> random test, TestPerColumnFamilyFlush. In my test run, it wrote 16M lines. It
> seems to be having zk issues but it is catching interrupts and ignoring them
> ([~carp84] fixed this in later versions over in HBASE-18441).
> Let me try and do some fixup under this umbrella so we can get a 1.2.7 out
> the door.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-19204) branch-1.2 times out and is taking 6-7 hours to complete
[
https://issues.apache.org/jira/browse/HBASE-19204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258038#comment-16258038
]
Chia-Ping Tsai edited comment on HBASE-19204 at 11/18/17 11:55 AM:
---
It is blocked when closing {{HttpServer2}}. Zoom in on the {{HttpServer2}}
{code}
@Test
public void testHttpServerHang() throws Exception {
for (int i = 0; i != 500; ++i) {
HttpServer2 server = null;
try {
Configuration conf = new Configuration();
conf.setInt("hadoop.http.max.threads", 10);
server = createTestServer(conf);
server.addServlet("echo", "/echo", TestHttpServer.EchoServlet.class);
server.addServlet("echomap", "/echomap",
TestHttpServer.EchoMapServlet.class);
server.addServlet("htmlcontent", "/htmlcontent",
TestHttpServer.HtmlContentServlet.class);
server.addServlet("longheader", "/longheader",
TestHttpServer.LongHeaderServlet.class);
server.addJerseyResourcePackage(
JerseyResource.class.getPackage().getName(), "/jersey/*");
server.start();
} finally {
if (server != null) {
server.stop();
}
}
}
}
{code}
And then i got the following stack dump.
{quote}
"2020688994@qtp-1069352689-1 - Acceptor0
HttpServer2$SelectChannelConnectorWithSafeStartup@localhost:39279" daemon
prio=10 tid=0x7fbd8c7a4000 nid=0x1c3e waiting for monitor entry
[0x7fbd740e1000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:464)
- waiting to lock <0xec24c798> (a
org.mortbay.io.nio.SelectorManager$SelectSet)
at org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:192)
at
org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124)
at
org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:708)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
"main" prio=10 tid=0x7fbd8c009000 nid=0x1bdc runnable [0x7fbd93ad5000]
java.lang.Thread.State: RUNNABLE
at
org.mortbay.io.nio.SelectorManager$SelectSet.stop(SelectorManager.java:878)
- locked <0xec24c798> (a
org.mortbay.io.nio.SelectorManager$SelectSet)
at org.mortbay.io.nio.SelectorManager.doStop(SelectorManager.java:240)
at
org.mortbay.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:76)
- locked <0xec07da28> (a java.lang.Object)
at
org.mortbay.jetty.nio.SelectChannelConnector.close(SelectChannelConnector.java:136)
{quote}
And then i noticed the same observation is already in the HBASE-14430 and
HBASE-14505. [~stack] Do you still look for the cryptic JVM version? :)
was (Author: chia7712):
It is blocked when closing {{HttpServer2}}. Zoom in on the {{HttpServer2}}
{code}
@Test
public void testHttpServerHang() throws Exception {
for (int i = 0; i != 500; ++i) {
HttpServer2 server = null;
try {
Configuration conf = new Configuration();
conf.setInt("hadoop.http.max.threads", 10);
server = createTestServer(conf);
server.addServlet("echo", "/echo", TestHttpServer.EchoServlet.class);
server.addServlet("echomap", "/echomap",
TestHttpServer.EchoMapServlet.class);
server.addServlet("htmlcontent", "/htmlcontent",
TestHttpServer.HtmlContentServlet.class);
server.addServlet("longheader", "/longheader",
TestHttpServer.LongHeaderServlet.class);
server.addJerseyResourcePackage(
JerseyResource.class.getPackage().getName(), "/jersey/*");
server.start();
} finally {
if (server != null) {
server.stop();
}
}
}
}
{code}
And then i got the following stack dump.
{quote}
"2020688994@qtp-1069352689-1 - Acceptor0
HttpServer2$SelectChannelConnectorWithSafeStartup@localhost:39279" daemon
prio=10 tid=0x7fbd8c7a4000 nid=0x1c3e waiting for monitor entry
[0x7fbd740e1000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:464)
- waiting to lock <0xec24c798> (a
org.mortbay.io.nio.SelectorManager$SelectSet)
at org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:192)
at
org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124)
at
org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:708)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
"main" prio=10 tid=0x7fbd8c009000 nid=0x1bdc runnable [0x7fbd93ad5000]
java.lang.Thread.State: RUNNABLE
at
org.mortbay.io.nio.SelectorManager$SelectSet.stop(SelectorManager.java:878)
- locked <0xec24c798> (a
[jira] [Created] (HBASE-19298) CellScanner should be declared as IA.Public
Chia-Ping Tsai created HBASE-19298:
--
Summary: CellScanner should be declared as IA.Public
Key: HBASE-19298
URL: https://issues.apache.org/jira/browse/HBASE-19298
Project: HBase
Issue Type: Task
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
User can create the {{CellScanner}} via IA.Public {{CellUtil}}, hence
{{CellScanner}} should be IA.Public. However, the {{CellScanner}} is used in
the server code base so making {{CellScanner}} IA.Public may flaw our HBASE in
the future. In my opinion, we should introduce the {{ExtendedCellScanner}} to
replace the {{CellScanner}} for server code.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19298) CellScanner should be declared as IA.Public
[
https://issues.apache.org/jira/browse/HBASE-19298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19298:
---
Fix Version/s: 2.0.0-beta-1
> CellScanner should be declared as IA.Public
> ---
>
> Key: HBASE-19298
> URL: https://issues.apache.org/jira/browse/HBASE-19298
> Project: HBase
> Issue Type: Task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-1
>
>
> User can create the {{CellScanner}} via IA.Public {{CellUtil}}, hence
> {{CellScanner}} should be IA.Public. However, the {{CellScanner}} is used in
> the server code base so making {{CellScanner}} IA.Public may flaw our HBASE
> in the future. In my opinion, we should introduce the {{ExtendedCellScanner}}
> to replace the {{CellScanner}} for server code.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19163) "Maximum lock count exceeded" from region server's batch processing
[
https://issues.apache.org/jira/browse/HBASE-19163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258120#comment-16258120
]
huaxiang sun commented on HBASE-19163:
--
Yeah [~allan163], that is a good idea. Let me cook up a new patch.
> "Maximum lock count exceeded" from region server's batch processing
> ---
>
> Key: HBASE-19163
> URL: https://issues.apache.org/jira/browse/HBASE-19163
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 3.0.0, 1.2.7, 2.0.0-alpha-3
>Reporter: huaxiang sun
>Assignee: huaxiang sun
> Attachments: HBASE-19163-master-v001.patch,
> HBASE-19163.master.001.patch, HBASE-19163.master.002.patch,
> HBASE-19163.master.004.patch, unittest-case.diff
>
>
> In one of use cases, we found the following exception and replication is
> stuck.
> {code}
> 2017-10-25 19:41:17,199 WARN [hconnection-0x28db294f-shared--pool4-t936]
> client.AsyncProcess: #3, table=foo, attempt=5/5 failed=262836ops, last
> exception: java.io.IOException: java.io.IOException: Maximum lock count
> exceeded
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2215)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:109)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:185)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:165)
> Caused by: java.lang.Error: Maximum lock count exceeded
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.fullTryAcquireShared(ReentrantReadWriteLock.java:528)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryAcquireShared(ReentrantReadWriteLock.java:488)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1327)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.tryLock(ReentrantReadWriteLock.java:871)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getRowLock(HRegion.java:5163)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutation(HRegion.java:3018)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2877)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2819)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doBatchOp(RSRpcServices.java:753)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doNonAtomicRegionMutation(RSRpcServices.java:715)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2148)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:33656)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2170)
> ... 3 more
> {code}
> While we are still examining the data pattern, it is sure that there are too
> many mutations in the batch against the same row, this exceeds the maximum
> 64k shared lock count and it throws an error and failed the whole batch.
> There are two approaches to solve this issue.
> 1). Let's say there are mutations against the same row in the batch, we just
> need to acquire the lock once for the same row vs to acquire the lock for
> each mutation.
> 2). We catch the error and start to process whatever it gets and loop back.
> With HBASE-17924, approach 1 seems easy to implement now.
> Create the jira and will post update/patch when investigation moving forward.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19298) CellScanner should be declared as IA.Public
[
https://issues.apache.org/jira/browse/HBASE-19298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258154#comment-16258154
]
Chia-Ping Tsai commented on HBASE-19298:
bq. what's special about CellScanner that we should make it public?
The {{CellScanner}} is nothing special I think. Our doc inspires me to file
this issue.
{code}
If you are relying on a particular interface that is marked Private, you should
open a jira to propose changing the interface to be Public or LimitedPrivate,
or an interface exposed for this purpose.
{code}
> CellScanner should be declared as IA.Public
> ---
>
> Key: HBASE-19298
> URL: https://issues.apache.org/jira/browse/HBASE-19298
> Project: HBase
> Issue Type: Task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19298.v0.patch
>
>
> User can create the {{CellScanner}} via IA.Public {{CellUtil}}, hence
> {{CellScanner}} should be IA.Public. However, the {{CellScanner}} is used in
> the server code base so making {{CellScanner}} IA.Public may flaw our HBASE
> in the future. In my opinion, we should introduce the {{ExtendedCellScanner}}
> to replace the {{CellScanner}} for server code.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19288) Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
[
https://issues.apache.org/jira/browse/HBASE-19288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-19288:
---
Attachment: 19288.v2.txt
> Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
> ---
>
> Key: HBASE-19288
> URL: https://issues.apache.org/jira/browse/HBASE-19288
> Project: HBase
> Issue Type: Test
> Components: test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19288.v1.txt, 19288.v2.txt,
> testRunDoubleMemStoreCompactors.out
>
>
> Here was one of the test failures:
> https://builds.apache.org/job/PreCommit-HBASE-Build/9812/testReport/junit/org.apache.hadoop.hbase.regionserver/TestHStore/testRunDoubleMemStoreCompactors/
>
> {code}
> [ERROR]
> org.apache.hadoop.hbase.regionserver.TestHStore.testRunDoubleMemStoreCompactors(org.apache.hadoop.hbase.regionserver.TestHStore)
> [ERROR] Run 1: TestHStore.testRunDoubleMemStoreCompactors:1500 expected:<2>
> but was:<3>
> [ERROR] Run 2: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<4>
> [ERROR] Run 3: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<5>
> {code}
> From the counts for second and third runs, we know that RUNNER_COUNT was not
> cleared in between the reruns, leading to failure at the 1st assertion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (HBASE-19299) Assert only one Connection is constructed when calculating splits in a MultiTableInputFormat
[ https://issues.apache.org/jira/browse/HBASE-19299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reassigned HBASE-19299: - Assignee: stack Component/s: test > Assert only one Connection is constructed when calculating splits in a > MultiTableInputFormat > > > Key: HBASE-19299 > URL: https://issues.apache.org/jira/browse/HBASE-19299 > Project: HBase > Issue Type: Test > Components: test >Reporter: stack >Assignee: stack >Priority: Minor > > Small test that verifies only one Connection made when calculating splits. We > used to put up one per Table until recently and before that, a Connection per > table per split which put a heavy load on hbase;meta. Here is a test to > ensure we don't go back to the bad-old-days. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18359) CoprocessorHConnection#getConnectionForEnvironment should read config from CoprocessorEnvironment
[
https://issues.apache.org/jira/browse/HBASE-18359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258239#comment-16258239
]
Samarth Jain commented on HBASE-18359:
--
We need our connections to have a different configuration that the one in
hbase-site.xml. The current custom configs mostly are related to remote RPCs,
so probably in case of short-circuit we can use the same connection as the RS
one. In future, it may change. So to avoid the any such hard to catch
regression, I think the best approach would be to just let the clients manage
the life cycle of the connection. Explicit documentation on the lines of "You
know what you are doing. And that creating too many connections will make you
run out of ZK resources, etc" would help. In Phoenix we guard against that by
caching the connection.
> CoprocessorHConnection#getConnectionForEnvironment should read config from
> CoprocessorEnvironment
> -
>
> Key: HBASE-18359
> URL: https://issues.apache.org/jira/browse/HBASE-18359
> Project: HBase
> Issue Type: Bug
>Reporter: Samarth Jain
> Fix For: 2.0.0
>
>
> It seems like the method getConnectionForEnvironment isn't doing the right
> thing when it is creating a CoprocessorHConnection by reading the config from
> HRegionServer and not from the env passed in.
> If coprocessors want to use a CoprocessorHConnection with some custom config
> settings, then they have no option but to configure it in the hbase-site.xml
> of the region servers. This isn't ideal as a lot of times these "global"
> level configs can have side effects. See PHOENIX-3974 as an example where
> configuring ServerRpcControllerFactory (a Phoenix implementation of
> RpcControllerFactory) could result in deadlocks. Or PHOENIX-3983 where
> presence of this global config causes our index rebuild code to incorrectly
> use handlers it shouldn't.
> If the CoprocessorHConnection created through getConnectionForEnvironment API
> used the CoprocessorEnvironment config, then it would allow co-processors to
> pass in their own config without needing to configure them in hbase-site.xml.
> The change would be simple. Basically change the below
> {code}
> if (services instanceof HRegionServer) {
> return new CoprocessorHConnection((HRegionServer) services);
> }
> {code}
> to
> {code}
> if (services instanceof HRegionServer) {
> return new CoprocessorHConnection(env.getConfiguration(),
> (HRegionServer) services);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19299) Assert only one Connection is constructed when calculating splits in a MultiTableInputFormat
stack created HBASE-19299: - Summary: Assert only one Connection is constructed when calculating splits in a MultiTableInputFormat Key: HBASE-19299 URL: https://issues.apache.org/jira/browse/HBASE-19299 Project: HBase Issue Type: Test Reporter: stack Priority: Minor Small test that verifies only one Connection made when calculating splits. We used to put up one per Table until recently and before that, a Connection per table per split which put a heavy load on hbase;meta. Here is a test to ensure we don't go back to the bad-old-days. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19299) Assert only one Connection is constructed when calculating splits in a MultiTableInputFormat
[ https://issues.apache.org/jira/browse/HBASE-19299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19299: -- Resolution: Fixed Fix Version/s: 3.0.0 Status: Resolved (was: Patch Available) Pushed to master only > Assert only one Connection is constructed when calculating splits in a > MultiTableInputFormat > > > Key: HBASE-19299 > URL: https://issues.apache.org/jira/browse/HBASE-19299 > Project: HBase > Issue Type: Test > Components: test >Reporter: stack >Assignee: stack >Priority: Minor > Fix For: 3.0.0 > > Attachments: > 0002-HBASE-19299-Assert-only-one-Connection-is-constructe.patch > > > Small test that verifies only one Connection made when calculating splits. We > used to put up one per Table until recently and before that, a Connection per > table per split which put a heavy load on hbase;meta. Here is a test to > ensure we don't go back to the bad-old-days. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19288) Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
[
https://issues.apache.org/jira/browse/HBASE-19288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258160#comment-16258160
]
Chia-Ping Tsai commented on HBASE-19288:
+1 on reseting the count, but I am curious about the failure in first run.
[~tedyu] any observation?
> Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
> ---
>
> Key: HBASE-19288
> URL: https://issues.apache.org/jira/browse/HBASE-19288
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
> Attachments: 19288.v1.txt, testRunDoubleMemStoreCompactors.out
>
>
> Here was one of the test failures:
> https://builds.apache.org/job/PreCommit-HBASE-Build/9812/testReport/junit/org.apache.hadoop.hbase.regionserver/TestHStore/testRunDoubleMemStoreCompactors/
>
> {code}
> [ERROR]
> org.apache.hadoop.hbase.regionserver.TestHStore.testRunDoubleMemStoreCompactors(org.apache.hadoop.hbase.regionserver.TestHStore)
> [ERROR] Run 1: TestHStore.testRunDoubleMemStoreCompactors:1500 expected:<2>
> but was:<3>
> [ERROR] Run 2: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<4>
> [ERROR] Run 3: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<5>
> {code}
> From the counts for second and third runs, we know that RUNNER_COUNT was not
> cleared in between the reruns, leading to failure at the 1st assertion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18359) CoprocessorHConnection#getConnectionForEnvironment should read config from CoprocessorEnvironment
[
https://issues.apache.org/jira/browse/HBASE-18359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258239#comment-16258239
]
Samarth Jain edited comment on HBASE-18359 at 11/18/17 10:34 PM:
-
We need our connections to have a different configuration than the one in
hbase-site.xml. The current custom configs mostly are related to remote RPCs,
so probably in case of short-circuit we can use the same connection as the RS
one. In future, it may change. So to avoid any such hard to catch regressions,
I think the best approach would be to just let the clients manage the life
cycle of the connection. Explicit documentation on the lines of "You know what
you are doing. And that creating too many connections will make you run out of
ZK resources, etc" would help. In Phoenix we guard against that by caching the
connection.
was (Author: samarthjain):
We need our connections to have a different configuration that the one in
hbase-site.xml. The current custom configs mostly are related to remote RPCs,
so probably in case of short-circuit we can use the same connection as the RS
one. In future, it may change. So to avoid the any such hard to catch
regression, I think the best approach would be to just let the clients manage
the life cycle of the connection. Explicit documentation on the lines of "You
know what you are doing. And that creating too many connections will make you
run out of ZK resources, etc" would help. In Phoenix we guard against that by
caching the connection.
> CoprocessorHConnection#getConnectionForEnvironment should read config from
> CoprocessorEnvironment
> -
>
> Key: HBASE-18359
> URL: https://issues.apache.org/jira/browse/HBASE-18359
> Project: HBase
> Issue Type: Bug
>Reporter: Samarth Jain
> Fix For: 2.0.0
>
>
> It seems like the method getConnectionForEnvironment isn't doing the right
> thing when it is creating a CoprocessorHConnection by reading the config from
> HRegionServer and not from the env passed in.
> If coprocessors want to use a CoprocessorHConnection with some custom config
> settings, then they have no option but to configure it in the hbase-site.xml
> of the region servers. This isn't ideal as a lot of times these "global"
> level configs can have side effects. See PHOENIX-3974 as an example where
> configuring ServerRpcControllerFactory (a Phoenix implementation of
> RpcControllerFactory) could result in deadlocks. Or PHOENIX-3983 where
> presence of this global config causes our index rebuild code to incorrectly
> use handlers it shouldn't.
> If the CoprocessorHConnection created through getConnectionForEnvironment API
> used the CoprocessorEnvironment config, then it would allow co-processors to
> pass in their own config without needing to configure them in hbase-site.xml.
> The change would be simple. Basically change the below
> {code}
> if (services instanceof HRegionServer) {
> return new CoprocessorHConnection((HRegionServer) services);
> }
> {code}
> to
> {code}
> if (services instanceof HRegionServer) {
> return new CoprocessorHConnection(env.getConfiguration(),
> (HRegionServer) services);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19299) Assert only one Connection is constructed when calculating splits in a MultiTableInputFormat
[ https://issues.apache.org/jira/browse/HBASE-19299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19299: -- Status: Patch Available (was: Open) > Assert only one Connection is constructed when calculating splits in a > MultiTableInputFormat > > > Key: HBASE-19299 > URL: https://issues.apache.org/jira/browse/HBASE-19299 > Project: HBase > Issue Type: Test > Components: test >Reporter: stack >Assignee: stack >Priority: Minor > Attachments: > 0002-HBASE-19299-Assert-only-one-Connection-is-constructe.patch > > > Small test that verifies only one Connection made when calculating splits. We > used to put up one per Table until recently and before that, a Connection per > table per split which put a heavy load on hbase;meta. Here is a test to > ensure we don't go back to the bad-old-days. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19247) [hbase-thirdparty] upgrade to Netty 4.1.17
[ https://issues.apache.org/jira/browse/HBASE-19247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258264#comment-16258264 ] stack commented on HBASE-19247: --- Ok. +1 > [hbase-thirdparty] upgrade to Netty 4.1.17 > -- > > Key: HBASE-19247 > URL: https://issues.apache.org/jira/browse/HBASE-19247 > Project: HBase > Issue Type: Bug > Components: dependencies, thirdparty >Reporter: Mike Drob >Assignee: Mike Drob > Fix For: thirdparty-1.0.2 > > Attachments: HBASE-19247.addendum.patch, > HBASE-19247.addendum.v2.patch, HBASE-19247.patch > > > Netty has a few newer versions that what we're on. Specifically, there have > been some changes to the native library loading that I think might make our > current relocated usage less terrible. > https://github.com/netty/netty/pull/6884 > https://github.com/netty/netty/pull/7102 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19299) Assert only one Connection is constructed when calculating splits in a MultiTableInputFormat
[ https://issues.apache.org/jira/browse/HBASE-19299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-19299: -- Attachment: 0002-HBASE-19299-Assert-only-one-Connection-is-constructe.patch > Assert only one Connection is constructed when calculating splits in a > MultiTableInputFormat > > > Key: HBASE-19299 > URL: https://issues.apache.org/jira/browse/HBASE-19299 > Project: HBase > Issue Type: Test > Components: test >Reporter: stack >Assignee: stack >Priority: Minor > Attachments: > 0002-HBASE-19299-Assert-only-one-Connection-is-constructe.patch > > > Small test that verifies only one Connection made when calculating splits. We > used to put up one per Table until recently and before that, a Connection per > table per split which put a heavy load on hbase;meta. Here is a test to > ensure we don't go back to the bad-old-days. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19288) Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
[
https://issues.apache.org/jira/browse/HBASE-19288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258273#comment-16258273
]
Hadoop QA commented on HBASE-19288:
---
| (/) *{color:green}+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:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m
2s{color} | {color:blue} The patch file was not named according to hbase's
naming conventions. Please see
https://yetus.apache.org/documentation/0.6.0/precommit-patchnames for
instructions. {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} 5m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
57s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 7m
1s{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
41s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
24s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
59m 32s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 2.7.4 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
38s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}121m
49s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
19s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}205m 43s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19288 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12898360/19288.v2.txt |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 3a0cea311563 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19
15:49:21 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 777b653b45 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9911/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9911/console |
| Powered by | Apache
[jira] [Updated] (HBASE-19288) Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
[
https://issues.apache.org/jira/browse/HBASE-19288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19288:
---
Component/s: test
> Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
> ---
>
> Key: HBASE-19288
> URL: https://issues.apache.org/jira/browse/HBASE-19288
> Project: HBase
> Issue Type: Test
> Components: test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19288.v1.txt, testRunDoubleMemStoreCompactors.out
>
>
> Here was one of the test failures:
> https://builds.apache.org/job/PreCommit-HBASE-Build/9812/testReport/junit/org.apache.hadoop.hbase.regionserver/TestHStore/testRunDoubleMemStoreCompactors/
>
> {code}
> [ERROR]
> org.apache.hadoop.hbase.regionserver.TestHStore.testRunDoubleMemStoreCompactors(org.apache.hadoop.hbase.regionserver.TestHStore)
> [ERROR] Run 1: TestHStore.testRunDoubleMemStoreCompactors:1500 expected:<2>
> but was:<3>
> [ERROR] Run 2: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<4>
> [ERROR] Run 3: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<5>
> {code}
> From the counts for second and third runs, we know that RUNNER_COUNT was not
> cleared in between the reruns, leading to failure at the 1st assertion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19288) Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
[
https://issues.apache.org/jira/browse/HBASE-19288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19288:
---
Fix Version/s: 2.0.0-beta-1
> Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
> ---
>
> Key: HBASE-19288
> URL: https://issues.apache.org/jira/browse/HBASE-19288
> Project: HBase
> Issue Type: Test
> Components: test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19288.v1.txt, testRunDoubleMemStoreCompactors.out
>
>
> Here was one of the test failures:
> https://builds.apache.org/job/PreCommit-HBASE-Build/9812/testReport/junit/org.apache.hadoop.hbase.regionserver/TestHStore/testRunDoubleMemStoreCompactors/
>
> {code}
> [ERROR]
> org.apache.hadoop.hbase.regionserver.TestHStore.testRunDoubleMemStoreCompactors(org.apache.hadoop.hbase.regionserver.TestHStore)
> [ERROR] Run 1: TestHStore.testRunDoubleMemStoreCompactors:1500 expected:<2>
> but was:<3>
> [ERROR] Run 2: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<4>
> [ERROR] Run 3: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<5>
> {code}
> From the counts for second and third runs, we know that RUNNER_COUNT was not
> cleared in between the reruns, leading to failure at the 1st assertion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (HBASE-19288) Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
[
https://issues.apache.org/jira/browse/HBASE-19288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai reassigned HBASE-19288:
--
Assignee: Ted Yu
> Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
> ---
>
> Key: HBASE-19288
> URL: https://issues.apache.org/jira/browse/HBASE-19288
> Project: HBase
> Issue Type: Test
> Components: test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19288.v1.txt, testRunDoubleMemStoreCompactors.out
>
>
> Here was one of the test failures:
> https://builds.apache.org/job/PreCommit-HBASE-Build/9812/testReport/junit/org.apache.hadoop.hbase.regionserver/TestHStore/testRunDoubleMemStoreCompactors/
>
> {code}
> [ERROR]
> org.apache.hadoop.hbase.regionserver.TestHStore.testRunDoubleMemStoreCompactors(org.apache.hadoop.hbase.regionserver.TestHStore)
> [ERROR] Run 1: TestHStore.testRunDoubleMemStoreCompactors:1500 expected:<2>
> but was:<3>
> [ERROR] Run 2: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<4>
> [ERROR] Run 3: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<5>
> {code}
> From the counts for second and third runs, we know that RUNNER_COUNT was not
> cleared in between the reruns, leading to failure at the 1st assertion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19204) branch-1.2 times out and is taking 6-7 hours to complete
[ https://issues.apache.org/jira/browse/HBASE-19204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258199#comment-16258199 ] stack commented on HBASE-19204: --- bq. Do you still look for the cryptic JVM version? Good stuff [~chia7712] You've seen HDFS-12711? It is about some (or various) items in hdfs that are blowing up tests. As you can tell I put the investigation aside. Seems like its back again with a vengeance. But how comes when I build locally w/ jdk8_73 I see timeouts (have not checked if they are same as the type you identify above ... I see similar looking timeouts on branch-2 builds... https://builds.apache.org/job/HBase%20Nightly/job/branch-2/119/artifact/output-jdk8/patch-unit-root.txt)? The old style 1.2 build is broke. https://builds.apache.org/view/H-L/view/HBase/job/HBase-1.2-JDK7/ It is using the 'latest' jdk7 available. The nightly jdk7 1.2 build is using 1.7.0_151 (one of the hangling jdk7s going by your finding above) and Apache Maven 3.0.5. /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java The last good nightly failed the hbase-server second part tests with timeouts... https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/131/artifact/output-jdk7/patch-unit-root.txt Possible to compile w/ 1.7 but run w/ 1.8 [~busbey]? Our yetus probably doesn't allow this? > branch-1.2 times out and is taking 6-7 hours to complete > > > Key: HBASE-19204 > URL: https://issues.apache.org/jira/browse/HBASE-19204 > Project: HBase > Issue Type: Umbrella > Components: test >Reporter: stack > > Sean has been looking at tooling and infra. This Umbrellas is about looking > at actual tests. For example, running locally on dedicated machine I picked a > random test, TestPerColumnFamilyFlush. In my test run, it wrote 16M lines. It > seems to be having zk issues but it is catching interrupts and ignoring them > ([~carp84] fixed this in later versions over in HBASE-18441). > Let me try and do some fixup under this umbrella so we can get a 1.2.7 out > the door. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18938) Backport HBASE-16985 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-18938: -- Status: Patch Available (was: In Progress) > Backport HBASE-16985 to branch-1.3 > -- > > Key: HBASE-18938 > URL: https://issues.apache.org/jira/browse/HBASE-18938 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1 >Reporter: Ashish Singhi >Assignee: Peter Somogyi > Fix For: 1.3.2 > > Attachments: HBASE-18938-branch-1.3.patch, > HBASE-18938-branch-1.3.patch, HBASE-18938-branch-1.3.v2.patch, > HBASE-18938-branch-1.3.v2.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18938) Backport HBASE-16985 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-18938: -- Status: In Progress (was: Patch Available) > Backport HBASE-16985 to branch-1.3 > -- > > Key: HBASE-18938 > URL: https://issues.apache.org/jira/browse/HBASE-18938 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1 >Reporter: Ashish Singhi >Assignee: Peter Somogyi > Fix For: 1.3.2 > > Attachments: HBASE-18938-branch-1.3.patch, > HBASE-18938-branch-1.3.patch, HBASE-18938-branch-1.3.v2.patch, > HBASE-18938-branch-1.3.v2.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19299) Assert only one Connection is constructed when calculating splits in a MultiTableInputFormat
[
https://issues.apache.org/jira/browse/HBASE-19299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258286#comment-16258286
]
Hadoop QA commented on HBASE-19299:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 2m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
10s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
14s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
16s{color} | {color:red} hbase-mapreduce: The patch generated 9 new + 0
unchanged - 0 fixed = 9 total (was 0) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
50s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
51m 4s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 2.7.4 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
14s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 13m
47s{color} | {color:green} hbase-mapreduce in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
9s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 83m 10s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19299 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12898368/0002-HBASE-19299-Assert-only-one-Connection-is-constructe.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux b63b0989cfc5 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 777b653b45 |
| 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/9912/artifact/patchprocess/diff-checkstyle-hbase-mapreduce.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9912/testReport/ |
| modules | C: hbase-mapreduce U: hbase-mapreduce |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9912/console |
| Powered by | Apache Yetus 0.6.0
[jira] [Commented] (HBASE-19169) Rowcounter job fails against hadoop3 beta1
[
https://issues.apache.org/jira/browse/HBASE-19169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258307#comment-16258307
]
Ted Yu commented on HBASE-19169:
Possibly related to the presence of hbase 1.2.6 jars (from ATS v2) in
mapreduce.tar.gz
> Rowcounter job fails against hadoop3 beta1
> --
>
> Key: HBASE-19169
> URL: https://issues.apache.org/jira/browse/HBASE-19169
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>
> I got the following error running rowcounter against hadoop3 beta1 based on
> commit a9f0c5d4e2c85c1faae1b4b277e3c290c8b81d2a :
> {code}
> 2017-11-03 17:10:59,583 INFO [main] mapreduce.Job: Task Id :
> attempt_1509641483571_0006_m_29_1, Status : FAILED
> Error: java.lang.ArrayIndexOutOfBoundsException: 2
> at
> org.apache.hadoop.hbase.mapreduce.TableSplit$Version.fromCode(TableSplit.java:77)
> at
> org.apache.hadoop.hbase.mapreduce.TableSplit.readFields(TableSplit.java:285)
> at
> org.apache.hadoop.io.serializer.WritableSerialization$WritableDeserializer.deserialize(WritableSerialization.java:71)
> at
> org.apache.hadoop.io.serializer.WritableSerialization$WritableDeserializer.deserialize(WritableSerialization.java:42)
> at org.apache.hadoop.mapred.MapTask.getSplitDetails(MapTask.java:372)
> at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:760)
> at org.apache.hadoop.mapred.MapTask.run(MapTask.java:341)
> at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1962)
> at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:168)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19288) Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
[
https://issues.apache.org/jira/browse/HBASE-19288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258306#comment-16258306
]
Chia-Ping Tsai commented on HBASE-19288:
+1
> Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
> ---
>
> Key: HBASE-19288
> URL: https://issues.apache.org/jira/browse/HBASE-19288
> Project: HBase
> Issue Type: Test
> Components: test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19288.v1.txt, 19288.v2.txt,
> testRunDoubleMemStoreCompactors.out
>
>
> Here was one of the test failures:
> https://builds.apache.org/job/PreCommit-HBASE-Build/9812/testReport/junit/org.apache.hadoop.hbase.regionserver/TestHStore/testRunDoubleMemStoreCompactors/
>
> {code}
> [ERROR]
> org.apache.hadoop.hbase.regionserver.TestHStore.testRunDoubleMemStoreCompactors(org.apache.hadoop.hbase.regionserver.TestHStore)
> [ERROR] Run 1: TestHStore.testRunDoubleMemStoreCompactors:1500 expected:<2>
> but was:<3>
> [ERROR] Run 2: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<4>
> [ERROR] Run 3: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<5>
> {code}
> From the counts for second and third runs, we know that RUNNER_COUNT was not
> cleared in between the reruns, leading to failure at the 1st assertion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19298) CellScanner should be declared as IA.Public
[
https://issues.apache.org/jira/browse/HBASE-19298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258141#comment-16258141
]
Sean Busbey commented on HBASE-19298:
-
There are plenty of places where our IA.Public API uses or returns
non-IA.Public members that folks are advised to treat as a black box. what's
special about CellScanner that we should make it public?
> CellScanner should be declared as IA.Public
> ---
>
> Key: HBASE-19298
> URL: https://issues.apache.org/jira/browse/HBASE-19298
> Project: HBase
> Issue Type: Task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19298.v0.patch
>
>
> User can create the {{CellScanner}} via IA.Public {{CellUtil}}, hence
> {{CellScanner}} should be IA.Public. However, the {{CellScanner}} is used in
> the server code base so making {{CellScanner}} IA.Public may flaw our HBASE
> in the future. In my opinion, we should introduce the {{ExtendedCellScanner}}
> to replace the {{CellScanner}} for server code.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18938) Backport HBASE-16985 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-18938: -- Attachment: HBASE-18938-branch-1.3.v2.patch > Backport HBASE-16985 to branch-1.3 > -- > > Key: HBASE-18938 > URL: https://issues.apache.org/jira/browse/HBASE-18938 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1 >Reporter: Ashish Singhi >Assignee: Peter Somogyi > Fix For: 1.3.2 > > Attachments: HBASE-18938-branch-1.3.patch, > HBASE-18938-branch-1.3.patch, HBASE-18938-branch-1.3.v2.patch, > HBASE-18938-branch-1.3.v2.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19288) Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
[
https://issues.apache.org/jira/browse/HBASE-19288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258161#comment-16258161
]
Ted Yu commented on HBASE-19288:
For the first failure, there was not enough information from test output.
That was why I added debug logs so that when the test fails again, we would
have more clue.
Planning to commit the patch Monday to master branch.
> Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
> ---
>
> Key: HBASE-19288
> URL: https://issues.apache.org/jira/browse/HBASE-19288
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
> Attachments: 19288.v1.txt, testRunDoubleMemStoreCompactors.out
>
>
> Here was one of the test failures:
> https://builds.apache.org/job/PreCommit-HBASE-Build/9812/testReport/junit/org.apache.hadoop.hbase.regionserver/TestHStore/testRunDoubleMemStoreCompactors/
>
> {code}
> [ERROR]
> org.apache.hadoop.hbase.regionserver.TestHStore.testRunDoubleMemStoreCompactors(org.apache.hadoop.hbase.regionserver.TestHStore)
> [ERROR] Run 1: TestHStore.testRunDoubleMemStoreCompactors:1500 expected:<2>
> but was:<3>
> [ERROR] Run 2: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<4>
> [ERROR] Run 3: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<5>
> {code}
> From the counts for second and third runs, we know that RUNNER_COUNT was not
> cleared in between the reruns, leading to failure at the 1st assertion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19288) Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
[
https://issues.apache.org/jira/browse/HBASE-19288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258204#comment-16258204
]
Chia-Ping Tsai commented on HBASE-19288:
The HBASE-16417 reduces the threshold of in-memory flush, hence the extra
in-memory flush may be executed before we evaluate the count.
{code}
Setting in-memory flush size threshold to 10
{code}
[~tedyu] Could you please add the following config to increase the threshold?
The {{0.25}} is the previous setting.
{code}
conf.set(CompactingMemStore.IN_MEMORY_FLUSH_THRESHOLD_FACTOR_KEY,
String.valueOf(0.25));
{code}
> Intermittent test failure in TestHStore.testRunDoubleMemStoreCompactors
> ---
>
> Key: HBASE-19288
> URL: https://issues.apache.org/jira/browse/HBASE-19288
> Project: HBase
> Issue Type: Test
> Components: test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19288.v1.txt, testRunDoubleMemStoreCompactors.out
>
>
> Here was one of the test failures:
> https://builds.apache.org/job/PreCommit-HBASE-Build/9812/testReport/junit/org.apache.hadoop.hbase.regionserver/TestHStore/testRunDoubleMemStoreCompactors/
>
> {code}
> [ERROR]
> org.apache.hadoop.hbase.regionserver.TestHStore.testRunDoubleMemStoreCompactors(org.apache.hadoop.hbase.regionserver.TestHStore)
> [ERROR] Run 1: TestHStore.testRunDoubleMemStoreCompactors:1500 expected:<2>
> but was:<3>
> [ERROR] Run 2: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<4>
> [ERROR] Run 3: TestHStore.testRunDoubleMemStoreCompactors:1481 expected:<1>
> but was:<5>
> {code}
> From the counts for second and third runs, we know that RUNNER_COUNT was not
> cleared in between the reruns, leading to failure at the 1st assertion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19298) CellScanner should be declared as IA.Public
[
https://issues.apache.org/jira/browse/HBASE-19298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258217#comment-16258217
]
Hadoop QA commented on HBASE-19298:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 2m
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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 7m
19s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
31s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
29s{color} | {color:green} hbase-common: The patch generated 0 new + 22
unchanged - 2 fixed = 22 total (was 24) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
35s{color} | {color:green} The patch hbase-client passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
8s{color} | {color:green} hbase-server: The patch generated 0 new + 10
unchanged - 1 fixed = 10 total (was 11) {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
8s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
57m 41s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 2.7.4 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
14s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
4s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}127m
36s{color} | {color:green} hbase-server in the patch passed. {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}221m 9s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19298 |
| JIRA Patch URL |
[jira] [Assigned] (HBASE-19159) Backup should check permission for snapshot copy in advance
[
https://issues.apache.org/jira/browse/HBASE-19159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu reassigned HBASE-19159:
--
Assignee: Janos Gub
> Backup should check permission for snapshot copy in advance
> ---
>
> Key: HBASE-19159
> URL: https://issues.apache.org/jira/browse/HBASE-19159
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Janos Gub
>Priority: Minor
> Attachments: initial_patch.txt
>
>
> When the user running the backup doesn't have permission to copy the snapshot
> , he / she would see:
> {code}
> 2017-11-02 18:21:33,654 ERROR [main] util.AbstractHBaseTool: Error running
> command-line tool
> org.apache.hadoop.hbase.snapshot.ExportSnapshotException: Failed to copy the
> snapshot directory:
> from=hdfs://ctr-e134-1499953498516-263664-01-03.hwx.site:8020/apps/hbase/data/.hbase-snapshot/snapshot_1509646891251_default_IntegrationTestBackupRestore.table2
>
> to=hdfs://ctr-e134-1499953498516-263664-01-03.hwx.site:8020/user/root/test-data/fb919a6f-3cb4-4d57-bbcf-561d6e5b3ae8/backupIT/backup_1509646884252/default/IntegrationTestBackupRestore.table2/.hbase-snapshot/.tmp/snapshot_1509646891251_default_IntegrationTestBackupRestore.table2
> at
> org.apache.hadoop.hbase.snapshot.ExportSnapshot.doWork(ExportSnapshot.java:1009)
> at
> org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:154)
> at
> org.apache.hadoop.hbase.backup.mapreduce.MapReduceBackupCopyJob.copy(MapReduceBackupCopyJob.java:386)
> at
> org.apache.hadoop.hbase.backup.impl.FullTableBackupClient.snapshotCopy(FullTableBackupClient.java:103)
> at
> org.apache.hadoop.hbase.backup.impl.FullTableBackupClient.execute(FullTableBackupClient.java:175)
> at
> org.apache.hadoop.hbase.backup.impl.BackupAdminImpl.backupTables(BackupAdminImpl.java:601)
> at
> org.apache.hadoop.hbase.IntegrationTestBackupRestore.runTest(IntegrationTestBackupRestore.java:180)
> at
> org.apache.hadoop.hbase.IntegrationTestBackupRestore.testBackupRestore(IntegrationTestBackupRestore.java:134)
> at
> org.apache.hadoop.hbase.IntegrationTestBackupRestore.runTestFromCommandLine(IntegrationTestBackupRestore.java:263)
> {code}
> It would be more user friendly if the permission is checked before taking the
> snapshot.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19300) TestMultithreadedTableMapper fails in branch-1.4
Ted Yu created HBASE-19300:
--
Summary: TestMultithreadedTableMapper fails in branch-1.4
Key: HBASE-19300
URL: https://issues.apache.org/jira/browse/HBASE-19300
Project: HBase
Issue Type: Test
Reporter: Ted Yu
>From
>https://builds.apache.org/job/HBase-1.4/1023/jdk=JDK_1_7,label=Hadoop&&!H13/testReport/org.apache.hadoop.hbase.mapreduce/TestMultithreadedTableMapper/testMultithreadedTableMapper/
> :
{code}
java.lang.AssertionError
at
org.apache.hadoop.hbase.mapreduce.TestMultithreadedTableMapper.verify(TestMultithreadedTableMapper.java:195)
at
org.apache.hadoop.hbase.mapreduce.TestMultithreadedTableMapper.runTestOnTable(TestMultithreadedTableMapper.java:163)
at
org.apache.hadoop.hbase.mapreduce.TestMultithreadedTableMapper.testMultithreadedTableMapper(TestMultithreadedTableMapper.java:136)
{code}
I ran the test locally which failed.
Noticed the following in test output:
{code}
2017-11-18 19:28:13,929 ERROR [hconnection-0x11db8653-shared--pool24-t9]
protobuf.ResponseConverter(425): Results sent from server=703. But only got 0
results completely atclient. Resetting the scanner to scan again.
2017-11-18 19:28:13,929 ERROR [hconnection-0x11db8653-shared--pool24-t3]
protobuf.ResponseConverter(425): Results sent from server=703. But only got 0
results completely atclient. Resetting the scanner to scan again.
2017-11-18 19:28:14,461 ERROR [hconnection-0x11db8653-shared--pool24-t8]
protobuf.ResponseConverter(432): Exception while reading cells from
result.Resetting the scanner toscan again.
org.apache.hadoop.hbase.DoNotRetryIOException: Results sent from server=703.
But only got 0 results completely at client. Resetting the scanner to scan
again.
at
org.apache.hadoop.hbase.protobuf.ResponseConverter.getResults(ResponseConverter.java:426)
at
org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:284)
at
org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:62)
at
org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:219)
at
org.apache.hadoop.hbase.client.ScannerCallableWithReplicas$RetryingRPC.call(ScannerCallableWithReplicas.java:388)
at
org.apache.hadoop.hbase.client.ScannerCallableWithReplicas$RetryingRPC.call(ScannerCallableWithReplicas.java:362)
at
org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:142)
at
org.apache.hadoop.hbase.client.ResultBoundedCompletionService$QueueingFuture.run(ResultBoundedCompletionService.java:80)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
2017-11-18 19:28:14,464 ERROR [hconnection-0x11db8653-shared--pool24-t2]
protobuf.ResponseConverter(432): Exception while reading cells from
result.Resetting the scanner toscan again.
java.io.EOFException: Partial cell read
at
org.apache.hadoop.hbase.codec.BaseDecoder.rethrowEofException(BaseDecoder.java:86)
at org.apache.hadoop.hbase.codec.BaseDecoder.advance(BaseDecoder.java:70)
at
org.apache.hadoop.hbase.protobuf.ResponseConverter.getResults(ResponseConverter.java:419)
at
org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:284)
at
org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:62)
at
org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:219)
at
org.apache.hadoop.hbase.client.ScannerCallableWithReplicas$RetryingRPC.call(ScannerCallableWithReplicas.java:388)
at
org.apache.hadoop.hbase.client.ScannerCallableWithReplicas$RetryingRPC.call(ScannerCallableWithReplicas.java:362)
at
org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:142)
at
org.apache.hadoop.hbase.client.ResultBoundedCompletionService$QueueingFuture.run(ResultBoundedCompletionService.java:80)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Premature EOF from inputStream
at org.apache.hadoop.io.IOUtils.readFully(IOUtils.java:202)
at org.apache.hadoop.hbase.KeyValueUtil.iscreate(KeyValueUtil.java:611)
at
org.apache.hadoop.hbase.codec.KeyValueCodec$KeyValueDecoder.parseCell(KeyValueCodec.java:69)
at org.apache.hadoop.hbase.codec.BaseDecoder.advance(BaseDecoder.java:67)
... 11 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-16985) TestClusterId failed due to wrong hbase rootdir
[
https://issues.apache.org/jira/browse/HBASE-16985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258320#comment-16258320
]
Hudson commented on HBASE-16985:
FAILURE: Integrated in Jenkins build HBase-1.3-JDK8 #372 (See
[https://builds.apache.org/job/HBase-1.3-JDK8/372/])
HBASE-18938 Backport HBASE-16985(TestClusterId failed due to wrong hbase
(chia7712: rev 48e6ad4404f9f47f9b952e7e2d434ff7ecf14aa3)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
> TestClusterId failed due to wrong hbase rootdir
> ---
>
> Key: HBASE-16985
> URL: https://issues.apache.org/jira/browse/HBASE-16985
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.1.7, 1.2.4
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.2.5, 1.1.9
>
> Attachments: HBASE-16985-branch-1.1.patch,
> HBASE-16985-branch-1.2.patch, HBASE-16985-branch-1.patch,
> HBASE-16985-branch-1.patch, HBASE-16985-v1.patch, HBASE-16985-v1.patch,
> HBASE-16985.patch
>
>
> https://builds.apache.org/job/PreCommit-HBASE-Build/4253/testReport/org.apache.hadoop.hbase.regionserver/TestClusterId/testClusterId/
> {code}
> java.io.IOException: Shutting down
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:230)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:409)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:227)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:96)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1071)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1037)
> at
> org.apache.hadoop.hbase.regionserver.TestClusterId.testClusterId(TestClusterId.java:85)
> {code}
> The cluster can not start up because there are no active master. The active
> master can not finish initialing because the hbase:namespace region can not
> be assign.
> In TestClusterId unit test, TEST_UTIL.startMiniHBaseCluster set new hbase
> root dir. But the regionserver thread which stared first used a different
> hbase root dir. If assign hbase:namespace region to this regionserver, the
> region can not be assigned because there are no tableinfo on wrong hbase root
> dir.
> When regionserver report to master, it will get back some new config. But the
> FSTableDescriptors has been initialed so it's root dir didn't changed.
> {code}
> if (LOG.isDebugEnabled()) {
> LOG.info("Config from master: " + key + "=" + value);
> }
> {code}
> I thought FSTableDescriptors need update the rootdir when regionserver get
> report from master.
> The master branch has same problem, too. But the balancer always assign
> hbase:namesapce region to master. So this unit test can passed on master
> branch.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18938) Backport HBASE-16985 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258319#comment-16258319 ] Hudson commented on HBASE-18938: FAILURE: Integrated in Jenkins build HBase-1.3-JDK8 #372 (See [https://builds.apache.org/job/HBase-1.3-JDK8/372/]) HBASE-18938 Backport HBASE-16985(TestClusterId failed due to wrong hbase (chia7712: rev 48e6ad4404f9f47f9b952e7e2d434ff7ecf14aa3) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java > Backport HBASE-16985 to branch-1.3 > -- > > Key: HBASE-18938 > URL: https://issues.apache.org/jira/browse/HBASE-18938 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1 >Reporter: Ashish Singhi >Assignee: Peter Somogyi > Fix For: 1.3.2 > > Attachments: HBASE-18938-branch-1.3.patch, > HBASE-18938-branch-1.3.patch, HBASE-18938-branch-1.3.v2.patch, > HBASE-18938-branch-1.3.v2.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18938) Backport HBASE-16985 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18938: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Push to branch-1.3. Thanks for the patch. [~psomogyi] and [~ashish singhi ] > Backport HBASE-16985 to branch-1.3 > -- > > Key: HBASE-18938 > URL: https://issues.apache.org/jira/browse/HBASE-18938 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1 >Reporter: Ashish Singhi >Assignee: Peter Somogyi > Fix For: 1.3.2 > > Attachments: HBASE-18938-branch-1.3.patch, > HBASE-18938-branch-1.3.patch, HBASE-18938-branch-1.3.v2.patch, > HBASE-18938-branch-1.3.v2.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[ https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258336#comment-16258336 ] ramkrishna.s.vasudevan commented on HBASE-16890: Sorry about the numbers. I don't have them now I think. I can run the test once again in a simple single node with PE and publish the numbers here. As far as which issue helped this I tried checking it but I was not able to narrow down on them. > Analyze the performance of AsyncWAL and fix the same > > > Key: HBASE-16890 > URL: https://issues.apache.org/jira/browse/HBASE-16890 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Blocker > Fix For: 2.0.0-beta-1 > > Attachments: AsyncWAL_disruptor.patch, AsyncWAL_disruptor_1 > (2).patch, AsyncWAL_disruptor_3.patch, AsyncWAL_disruptor_3.patch, > AsyncWAL_disruptor_4.patch, AsyncWAL_disruptor_6.patch, > HBASE-16890-rc-v2.patch, HBASE-16890-rc-v3.patch, > HBASE-16890-remove-contention-v1.patch, HBASE-16890-remove-contention.patch, > Screen Shot 2016-10-25 at 7.34.47 PM.png, Screen Shot 2016-10-25 at 7.39.07 > PM.png, Screen Shot 2016-10-25 at 7.39.48 PM.png, Screen Shot 2016-11-04 at > 5.21.27 PM.png, Screen Shot 2016-11-04 at 5.30.18 PM.png, async.svg, > classic.svg, contention.png, contention_defaultWAL.png > > > Tests reveal that AsyncWAL under load in single node cluster performs slower > than the Default WAL. This task is to analyze and see if we could fix it. > See some discussions in the tail of JIRA HBASE-15536. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18938) Backport HBASE-16985 to branch-1.3
[
https://issues.apache.org/jira/browse/HBASE-18938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258315#comment-16258315
]
Chia-Ping Tsai commented on HBASE-18938:
The
[build|https://builds.apache.org/view/H-L/view/HBase/job/PreCommit-HBASE-Build/9910/console]
is dead. I run the build locally.
{code}
07:14:53 | Vote | Subsystem | Runtime | Comment
07:14:53
07:14:53 | | || Prechecks
07:14:53 | +1 | hbaseanti | 0m 0s | Patch does not have any
anti-patterns.
07:14:53 | +1 |@author | 0m 0s | The patch does not contain any
@author
07:14:53 | | || tags.
07:14:53 | -1 | test4tests | 0m 0s | The patch doesn't appear to
include any
07:14:53 | | || new or modified tests. Please
justify
07:14:53 | | || why no new tests are needed
for this
07:14:53 | | || patch. Also please list what
manual
07:14:53 | | || steps were performed to verify
this
07:14:53 | | || patch.
07:14:53 | | || branch-1.3 Compile Tests
07:14:53 | +1 | mvninstall | 1m 57s | branch-1.3 passed
07:14:53 | +1 |compile | 0m 32s | branch-1.3 passed
07:14:53 | +1 | checkstyle | 1m 17s | branch-1.3 passed
07:14:53 | +1 | findbugs | 1m 40s | branch-1.3 passed
07:14:53 | +1 |javadoc | 0m 56s | branch-1.3 passed
07:14:53 | | || Patch Compile Tests
07:14:53 | +1 | mvninstall | 0m 43s | the patch passed
07:14:53 | +1 |compile | 0m 33s | the patch passed
07:14:53 | +1 | javac | 0m 33s | the patch passed
07:14:53 | +1 | checkstyle | 1m 0s | the patch passed
07:14:53 | +1 | whitespace | 0m 0s | The patch has no whitespace
issues.
07:14:53 | +1 |hadoopcheck | 17m 24s | The patch does not cause any
errors
07:14:53 | | || with Hadoop 2.4.0 2.4.1 2.5.0
2.5.1
07:14:53 | | || 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1.
07:14:53 | +1 | findbugs | 1m 44s | the patch passed
07:14:53 | +1 |javadoc | 0m 27s | the patch passed
07:14:53 | | || Other Tests
07:14:54 | -1 | unit | 104m 13s | hbase-server in the patch
failed.
07:14:54 | +1 | asflicense | 0m 38s | The patch does not generate
ASF License
07:14:54 | | || warnings.
07:14:54 | | | 133m 35s |
{code}
The failed test is {{TestHRegion}}, and it pass by the command {{mvn clean test
-Dtest=TestHRegion}}.
+1 on v2. Will commit it later.
> Backport HBASE-16985 to branch-1.3
> --
>
> Key: HBASE-18938
> URL: https://issues.apache.org/jira/browse/HBASE-18938
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 1.3.1
>Reporter: Ashish Singhi
>Assignee: Peter Somogyi
> Fix For: 1.3.2
>
> Attachments: HBASE-18938-branch-1.3.patch,
> HBASE-18938-branch-1.3.patch, HBASE-18938-branch-1.3.v2.patch,
> HBASE-18938-branch-1.3.v2.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-16985) TestClusterId failed due to wrong hbase rootdir
[
https://issues.apache.org/jira/browse/HBASE-16985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258325#comment-16258325
]
Hudson commented on HBASE-16985:
FAILURE: Integrated in Jenkins build HBase-1.3-IT #292 (See
[https://builds.apache.org/job/HBase-1.3-IT/292/])
HBASE-18938 Backport HBASE-16985(TestClusterId failed due to wrong hbase
(chia7712: rev 48e6ad4404f9f47f9b952e7e2d434ff7ecf14aa3)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
> TestClusterId failed due to wrong hbase rootdir
> ---
>
> Key: HBASE-16985
> URL: https://issues.apache.org/jira/browse/HBASE-16985
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.1.7, 1.2.4
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.2.5, 1.1.9
>
> Attachments: HBASE-16985-branch-1.1.patch,
> HBASE-16985-branch-1.2.patch, HBASE-16985-branch-1.patch,
> HBASE-16985-branch-1.patch, HBASE-16985-v1.patch, HBASE-16985-v1.patch,
> HBASE-16985.patch
>
>
> https://builds.apache.org/job/PreCommit-HBASE-Build/4253/testReport/org.apache.hadoop.hbase.regionserver/TestClusterId/testClusterId/
> {code}
> java.io.IOException: Shutting down
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:230)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:409)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:227)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:96)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1071)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1037)
> at
> org.apache.hadoop.hbase.regionserver.TestClusterId.testClusterId(TestClusterId.java:85)
> {code}
> The cluster can not start up because there are no active master. The active
> master can not finish initialing because the hbase:namespace region can not
> be assign.
> In TestClusterId unit test, TEST_UTIL.startMiniHBaseCluster set new hbase
> root dir. But the regionserver thread which stared first used a different
> hbase root dir. If assign hbase:namespace region to this regionserver, the
> region can not be assigned because there are no tableinfo on wrong hbase root
> dir.
> When regionserver report to master, it will get back some new config. But the
> FSTableDescriptors has been initialed so it's root dir didn't changed.
> {code}
> if (LOG.isDebugEnabled()) {
> LOG.info("Config from master: " + key + "=" + value);
> }
> {code}
> I thought FSTableDescriptors need update the rootdir when regionserver get
> report from master.
> The master branch has same problem, too. But the balancer always assign
> hbase:namesapce region to master. So this unit test can passed on master
> branch.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18938) Backport HBASE-16985 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258324#comment-16258324 ] Hudson commented on HBASE-18938: FAILURE: Integrated in Jenkins build HBase-1.3-IT #292 (See [https://builds.apache.org/job/HBase-1.3-IT/292/]) HBASE-18938 Backport HBASE-16985(TestClusterId failed due to wrong hbase (chia7712: rev 48e6ad4404f9f47f9b952e7e2d434ff7ecf14aa3) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java > Backport HBASE-16985 to branch-1.3 > -- > > Key: HBASE-18938 > URL: https://issues.apache.org/jira/browse/HBASE-18938 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1 >Reporter: Ashish Singhi >Assignee: Peter Somogyi > Fix For: 1.3.2 > > Attachments: HBASE-18938-branch-1.3.patch, > HBASE-18938-branch-1.3.patch, HBASE-18938-branch-1.3.v2.patch, > HBASE-18938-branch-1.3.v2.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18937) Backport HBASE-16815 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18937: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Push to branch-1.3. Thanks for the patch. [~ashish singhi] > Backport HBASE-16815 to branch-1.3 > -- > > Key: HBASE-18937 > URL: https://issues.apache.org/jira/browse/HBASE-18937 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1 >Reporter: Ashish Singhi >Assignee: Ashish Singhi > Fix For: 1.3.2 > > Attachments: HBASE-18937-branch-1.3.patch, > HBASE-18937-branch-1.3.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16985) TestClusterId failed due to wrong hbase rootdir
[
https://issues.apache.org/jira/browse/HBASE-16985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258323#comment-16258323
]
Hudson commented on HBASE-16985:
FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #352 (See
[https://builds.apache.org/job/HBase-1.3-JDK7/352/])
HBASE-18938 Backport HBASE-16985(TestClusterId failed due to wrong hbase
(chia7712: rev 48e6ad4404f9f47f9b952e7e2d434ff7ecf14aa3)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
> TestClusterId failed due to wrong hbase rootdir
> ---
>
> Key: HBASE-16985
> URL: https://issues.apache.org/jira/browse/HBASE-16985
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.1.7, 1.2.4
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.2.5, 1.1.9
>
> Attachments: HBASE-16985-branch-1.1.patch,
> HBASE-16985-branch-1.2.patch, HBASE-16985-branch-1.patch,
> HBASE-16985-branch-1.patch, HBASE-16985-v1.patch, HBASE-16985-v1.patch,
> HBASE-16985.patch
>
>
> https://builds.apache.org/job/PreCommit-HBASE-Build/4253/testReport/org.apache.hadoop.hbase.regionserver/TestClusterId/testClusterId/
> {code}
> java.io.IOException: Shutting down
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:230)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:409)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:227)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:96)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1071)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1037)
> at
> org.apache.hadoop.hbase.regionserver.TestClusterId.testClusterId(TestClusterId.java:85)
> {code}
> The cluster can not start up because there are no active master. The active
> master can not finish initialing because the hbase:namespace region can not
> be assign.
> In TestClusterId unit test, TEST_UTIL.startMiniHBaseCluster set new hbase
> root dir. But the regionserver thread which stared first used a different
> hbase root dir. If assign hbase:namespace region to this regionserver, the
> region can not be assigned because there are no tableinfo on wrong hbase root
> dir.
> When regionserver report to master, it will get back some new config. But the
> FSTableDescriptors has been initialed so it's root dir didn't changed.
> {code}
> if (LOG.isDebugEnabled()) {
> LOG.info("Config from master: " + key + "=" + value);
> }
> {code}
> I thought FSTableDescriptors need update the rootdir when regionserver get
> report from master.
> The master branch has same problem, too. But the balancer always assign
> hbase:namesapce region to master. So this unit test can passed on master
> branch.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18936) Backport HBASE-16870 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258321#comment-16258321 ] Chia-Ping Tsai commented on HBASE-18936: [~psomogyi] Do you want take this up? > Backport HBASE-16870 to branch-1.3 > -- > > Key: HBASE-18936 > URL: https://issues.apache.org/jira/browse/HBASE-18936 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1 >Reporter: Ashish Singhi > Fix For: 1.3.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18938) Backport HBASE-16985 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258322#comment-16258322 ] Hudson commented on HBASE-18938: FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #352 (See [https://builds.apache.org/job/HBase-1.3-JDK7/352/]) HBASE-18938 Backport HBASE-16985(TestClusterId failed due to wrong hbase (chia7712: rev 48e6ad4404f9f47f9b952e7e2d434ff7ecf14aa3) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java > Backport HBASE-16985 to branch-1.3 > -- > > Key: HBASE-18938 > URL: https://issues.apache.org/jira/browse/HBASE-18938 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1 >Reporter: Ashish Singhi >Assignee: Peter Somogyi > Fix For: 1.3.2 > > Attachments: HBASE-18938-branch-1.3.patch, > HBASE-18938-branch-1.3.patch, HBASE-18938-branch-1.3.v2.patch, > HBASE-18938-branch-1.3.v2.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19180) Remove unused imports from AlwaysPasses
[ https://issues.apache.org/jira/browse/HBASE-19180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258342#comment-16258342 ] Chia-Ping Tsai commented on HBASE-19180: bq. Chia-Ping Tsai I already had HBASE-17663 for this half a year ago, but I would guess that this one is way out of date. I would close it, because it handles the whole code base, instead of breaking it down into smaller pieces. We can put it as sub-tasks into HBASE-12521. Any update? > Remove unused imports from AlwaysPasses > --- > > Key: HBASE-19180 > URL: https://issues.apache.org/jira/browse/HBASE-19180 > Project: HBase > Issue Type: Improvement > Components: build >Affects Versions: 3.0.0 >Reporter: Jan Hentschel >Assignee: Jan Hentschel >Priority: Trivial > Attachments: HBASE-19180.master.001.patch > > > The class org.apache.hadoop.hbase.errorprone.AlwaysPasses currently has some > unused imports, which should be removed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19299) Assert only one Connection is constructed when calculating splits in a MultiTableInputFormat
[ https://issues.apache.org/jira/browse/HBASE-19299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258344#comment-16258344 ] Hudson commented on HBASE-19299: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4079 (See [https://builds.apache.org/job/HBase-Trunk_matrix/4079/]) HBASE-19299 Assert only one Connection is constructed when calculating (stack: rev b4fbf5fe18bc9247106f674580666096fd34d3fa) * (add) hbase-mapreduce/src/test/java/org/apache/hadoop/hbase/mapreduce/TestMultiTableInputFormatBase.java > Assert only one Connection is constructed when calculating splits in a > MultiTableInputFormat > > > Key: HBASE-19299 > URL: https://issues.apache.org/jira/browse/HBASE-19299 > Project: HBase > Issue Type: Test > Components: test >Reporter: stack >Assignee: stack >Priority: Minor > Fix For: 3.0.0 > > Attachments: > 0002-HBASE-19299-Assert-only-one-Connection-is-constructe.patch > > > Small test that verifies only one Connection made when calculating splits. We > used to put up one per Table until recently and before that, a Connection per > table per split which put a heavy load on hbase;meta. Here is a test to > ensure we don't go back to the bad-old-days. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19266) TestAcidGuarantees should cover adaptive in-memory compaction
[ https://issues.apache.org/jira/browse/HBASE-19266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258350#comment-16258350 ] Chia-Ping Tsai commented on HBASE-19266: [~tedyu] Do you have the patch? > TestAcidGuarantees should cover adaptive in-memory compaction > - > > Key: HBASE-19266 > URL: https://issues.apache.org/jira/browse/HBASE-19266 > Project: HBase > Issue Type: Test >Reporter: Ted Yu >Priority: Minor > > Currently TestAcidGuarantees populates 3 policies of (in-memory) compaction. > Adaptive in-memory compaction is new and should be added as 4th compaction > policy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16890) Analyze the performance of AsyncWAL and fix the same
[
https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258363#comment-16258363
]
ramkrishna.s.vasudevan commented on HBASE-16890:
I got those numbers. Just loaded 25G with 50 threads with PE tool. Avg
completion time is below
Normal WAL
{code}
Avg: 164583ms
{code}
Async WAL
{code}
Avg: 133019ms
{code}
So we have 19% improvement. Is this test enough?
> Analyze the performance of AsyncWAL and fix the same
>
>
> Key: HBASE-16890
> URL: https://issues.apache.org/jira/browse/HBASE-16890
> Project: HBase
> Issue Type: Sub-task
> Components: wal
>Affects Versions: 2.0.0
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Blocker
> Fix For: 2.0.0-beta-1
>
> Attachments: AsyncWAL_disruptor.patch, AsyncWAL_disruptor_1
> (2).patch, AsyncWAL_disruptor_3.patch, AsyncWAL_disruptor_3.patch,
> AsyncWAL_disruptor_4.patch, AsyncWAL_disruptor_6.patch,
> HBASE-16890-rc-v2.patch, HBASE-16890-rc-v3.patch,
> HBASE-16890-remove-contention-v1.patch, HBASE-16890-remove-contention.patch,
> Screen Shot 2016-10-25 at 7.34.47 PM.png, Screen Shot 2016-10-25 at 7.39.07
> PM.png, Screen Shot 2016-10-25 at 7.39.48 PM.png, Screen Shot 2016-11-04 at
> 5.21.27 PM.png, Screen Shot 2016-11-04 at 5.30.18 PM.png, async.svg,
> classic.svg, contention.png, contention_defaultWAL.png
>
>
> Tests reveal that AsyncWAL under load in single node cluster performs slower
> than the Default WAL. This task is to analyze and see if we could fix it.
> See some discussions in the tail of JIRA HBASE-15536.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19298) CellScanner should be declared as IA.Public
[
https://issues.apache.org/jira/browse/HBASE-19298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258316#comment-16258316
]
Chia-Ping Tsai commented on HBASE-19298:
bq. There are plenty of places where our IA.Public API uses or returns
non-IA.Public members that folks are advised to treat as a black box.
Is it the consensus in our community? If so, I'm fine to close this issue as
{{Won't Fix}}. :)
> CellScanner should be declared as IA.Public
> ---
>
> Key: HBASE-19298
> URL: https://issues.apache.org/jira/browse/HBASE-19298
> Project: HBase
> Issue Type: Task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19298.v0.patch
>
>
> User can create the {{CellScanner}} via IA.Public {{CellUtil}}, hence
> {{CellScanner}} should be IA.Public. However, the {{CellScanner}} is used in
> the server code base so making {{CellScanner}} IA.Public may flaw our HBASE
> in the future. In my opinion, we should introduce the {{ExtendedCellScanner}}
> to replace the {{CellScanner}} for server code.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19123) Purge 'complete' support from Coprocesor Observers
[ https://issues.apache.org/jira/browse/HBASE-19123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258343#comment-16258343 ] Hudson commented on HBASE-19123: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4079 (See [https://builds.apache.org/job/HBase-Trunk_matrix/4079/]) HBASE-19123 Purge 'complete' support from Coprocesor Observers (stack: rev 08544e54a999df16cb0cef7cf45a17da1eeef42d) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/RegionObserver.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/mob/compactions/TestMobCompactor.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/ObserverContext.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/ObserverContextImpl.java > Purge 'complete' support from Coprocesor Observers > -- > > Key: HBASE-19123 > URL: https://issues.apache.org/jira/browse/HBASE-19123 > Project: HBase > Issue Type: Task > Components: Coprocessors >Reporter: stack >Assignee: stack > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19123.master.001.patch, > HBASE-19123.master.002.patch, HBASE-19123.master.003.patch, > HBASE-19123.master.004.patch > > > Up on dev list under '[DISCUSSION] Removing the bypass semantic from the > Coprocessor APIs', we are discussing purge of 'complete'. Unless objection, > lets purge for beta-1. > [~andrew.purt...@gmail.com] says the following up on the dev list: > It would simplify the theory of operation for coprocessors if we can assume > either the entire chain will complete or one of the coprocessors in the chain > will throw an exception that not only terminates processing of the rest of > the chain but also the operation in progress. > Security coprocessors interrupt processing by throwing an exception, which is > meant to propagate all the way back to the user. > I think it's more than fair to ask the same question about 'complete' as we > did about 'bypass': Does anyone use it? Is it needed? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16815) Low scan ratio in RPC queue tuning triggers divide by zero exception
[
https://issues.apache.org/jira/browse/HBASE-16815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258370#comment-16258370
]
Hudson commented on HBASE-16815:
FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #353 (See
[https://builds.apache.org/job/HBase-1.3-JDK7/353/])
HBASE-18937 Backport HBASE-16815(Low scan ratio in RPC queue tuning (chia7712:
rev 1ae312f270c71f7ccbc2c4c8560035e3418ccc92)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RWQueueRpcExecutor.java
> Low scan ratio in RPC queue tuning triggers divide by zero exception
>
>
> Key: HBASE-16815
> URL: https://issues.apache.org/jira/browse/HBASE-16815
> Project: HBase
> Issue Type: Bug
> Components: regionserver, rpc
>Affects Versions: 2.0.0, 1.3.0
>Reporter: Lars George
>Assignee: Guanghao Zhang
> Fix For: 2.0.0, 1.4.0, 1.2.4, 1.1.8
>
> Attachments: HBASE-16815-branch-1.2.patch, HBASE-16815.patch
>
>
> Trying the following settings:
> {noformat}
>
> hbase.ipc.server.callqueue.handler.factor
> 0.5
>
>
> hbase.ipc.server.callqueue.read.ratio
> 0.5
>
>
> hbase.ipc.server.callqueue.scan.ratio
> 0.1
>
> {noformat}
> With 30 default handlers, this means 15 queues. Further, it means 8 write
> queues and 7 read queues. 10% of that is {{0.7}} which is then floor'ed to
> {{0}}. The debug log confirms it, as the tertiary check omits the scan
> details when they are zero:
> {noformat}
> 2016-10-12 12:50:27,305 INFO [main] ipc.SimpleRpcScheduler: Using fifo as
> user call queue, count=15
> 2016-10-12 12:50:27,311 DEBUG [main] ipc.RWQueueRpcExecutor: FifoRWQ.default
> writeQueues=7 writeHandlers=15 readQueues=8 readHandlers=14
> {noformat}
> But the code in {{RWQueueRpcExecutor}} calls {{RpcExecutor.startHandler()}}
> nevertheless and that does this:
> {code}
> for (int i = 0; i < numHandlers; i++) {
> final int index = qindex + (i % qsize);
> String name = "RpcServer." + threadPrefix + ".handler=" +
> handlers.size() + ",queue=" +
> index + ",port=" + port;
> {code}
> The modulo triggers then
> {noformat}
> 2016-10-12 11:41:22,810 ERROR [main] master.HMasterCommandLine: Master exiting
> java.lang.RuntimeException: Failed construction of Master: class
> org.apache.hadoop.hbase.master.HMasterCommandLine$LocalHMaster
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.createMasterThread(JVMClusterUtil.java:145)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.addMaster(LocalHBaseCluster.java:220)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.(LocalHBaseCluster.java:155)
> at
> org.apache.hadoop.hbase.master.HMasterCommandLine.startMaster(HMasterCommandLine.java:222)
> at
> org.apache.hadoop.hbase.master.HMasterCommandLine.run(HMasterCommandLine.java:137)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
> at
> org.apache.hadoop.hbase.util.ServerCommandLine.doMain(ServerCommandLine.java:126)
> at org.apache.hadoop.hbase.master.HMaster.main(HMaster.java:2524)
> Caused by: java.lang.ArithmeticException: / by zero
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.startHandlers(RpcExecutor.java:125)
> at
> org.apache.hadoop.hbase.ipc.RWQueueRpcExecutor.startHandlers(RWQueueRpcExecutor.java:178)
> at org.apache.hadoop.hbase.ipc.RpcExecutor.start(RpcExecutor.java:78)
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.start(SimpleRpcScheduler.java:272)
> at org.apache.hadoop.hbase.ipc.RpcServer.start(RpcServer.java:2212)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.start(RSRpcServices.java:1143)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.(HRegionServer.java:615)
> at org.apache.hadoop.hbase.master.HMaster.(HMaster.java:396)
> at
> org.apache.hadoop.hbase.master.HMasterCommandLine$LocalHMaster.(HMasterCommandLine.java:312)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.createMasterThread(JVMClusterUtil.java:140)
> ... 7 more
> {noformat}
> That causes the server to not even start. I would suggest we either skip the
> {{startHandler()}} call altogether, or make it zero aware.
> Another possible option is to reserve at least _one_ scan handler/queue when
> the scan ratio is greater than zero, but only of there is more than one read
> handler/queue to begin
[jira] [Commented] (HBASE-16815) Low scan ratio in RPC queue tuning triggers divide by zero exception
[
https://issues.apache.org/jira/browse/HBASE-16815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258367#comment-16258367
]
Hudson commented on HBASE-16815:
FAILURE: Integrated in Jenkins build HBase-1.3-JDK8 #373 (See
[https://builds.apache.org/job/HBase-1.3-JDK8/373/])
HBASE-18937 Backport HBASE-16815(Low scan ratio in RPC queue tuning (chia7712:
rev 1ae312f270c71f7ccbc2c4c8560035e3418ccc92)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RWQueueRpcExecutor.java
> Low scan ratio in RPC queue tuning triggers divide by zero exception
>
>
> Key: HBASE-16815
> URL: https://issues.apache.org/jira/browse/HBASE-16815
> Project: HBase
> Issue Type: Bug
> Components: regionserver, rpc
>Affects Versions: 2.0.0, 1.3.0
>Reporter: Lars George
>Assignee: Guanghao Zhang
> Fix For: 2.0.0, 1.4.0, 1.2.4, 1.1.8
>
> Attachments: HBASE-16815-branch-1.2.patch, HBASE-16815.patch
>
>
> Trying the following settings:
> {noformat}
>
> hbase.ipc.server.callqueue.handler.factor
> 0.5
>
>
> hbase.ipc.server.callqueue.read.ratio
> 0.5
>
>
> hbase.ipc.server.callqueue.scan.ratio
> 0.1
>
> {noformat}
> With 30 default handlers, this means 15 queues. Further, it means 8 write
> queues and 7 read queues. 10% of that is {{0.7}} which is then floor'ed to
> {{0}}. The debug log confirms it, as the tertiary check omits the scan
> details when they are zero:
> {noformat}
> 2016-10-12 12:50:27,305 INFO [main] ipc.SimpleRpcScheduler: Using fifo as
> user call queue, count=15
> 2016-10-12 12:50:27,311 DEBUG [main] ipc.RWQueueRpcExecutor: FifoRWQ.default
> writeQueues=7 writeHandlers=15 readQueues=8 readHandlers=14
> {noformat}
> But the code in {{RWQueueRpcExecutor}} calls {{RpcExecutor.startHandler()}}
> nevertheless and that does this:
> {code}
> for (int i = 0; i < numHandlers; i++) {
> final int index = qindex + (i % qsize);
> String name = "RpcServer." + threadPrefix + ".handler=" +
> handlers.size() + ",queue=" +
> index + ",port=" + port;
> {code}
> The modulo triggers then
> {noformat}
> 2016-10-12 11:41:22,810 ERROR [main] master.HMasterCommandLine: Master exiting
> java.lang.RuntimeException: Failed construction of Master: class
> org.apache.hadoop.hbase.master.HMasterCommandLine$LocalHMaster
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.createMasterThread(JVMClusterUtil.java:145)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.addMaster(LocalHBaseCluster.java:220)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.(LocalHBaseCluster.java:155)
> at
> org.apache.hadoop.hbase.master.HMasterCommandLine.startMaster(HMasterCommandLine.java:222)
> at
> org.apache.hadoop.hbase.master.HMasterCommandLine.run(HMasterCommandLine.java:137)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
> at
> org.apache.hadoop.hbase.util.ServerCommandLine.doMain(ServerCommandLine.java:126)
> at org.apache.hadoop.hbase.master.HMaster.main(HMaster.java:2524)
> Caused by: java.lang.ArithmeticException: / by zero
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.startHandlers(RpcExecutor.java:125)
> at
> org.apache.hadoop.hbase.ipc.RWQueueRpcExecutor.startHandlers(RWQueueRpcExecutor.java:178)
> at org.apache.hadoop.hbase.ipc.RpcExecutor.start(RpcExecutor.java:78)
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.start(SimpleRpcScheduler.java:272)
> at org.apache.hadoop.hbase.ipc.RpcServer.start(RpcServer.java:2212)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.start(RSRpcServices.java:1143)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.(HRegionServer.java:615)
> at org.apache.hadoop.hbase.master.HMaster.(HMaster.java:396)
> at
> org.apache.hadoop.hbase.master.HMasterCommandLine$LocalHMaster.(HMasterCommandLine.java:312)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.createMasterThread(JVMClusterUtil.java:140)
> ... 7 more
> {noformat}
> That causes the server to not even start. I would suggest we either skip the
> {{startHandler()}} call altogether, or make it zero aware.
> Another possible option is to reserve at least _one_ scan handler/queue when
> the scan ratio is greater than zero, but only of there is more than one read
> handler/queue to begin
[jira] [Commented] (HBASE-18937) Backport HBASE-16815 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258366#comment-16258366 ] Hudson commented on HBASE-18937: FAILURE: Integrated in Jenkins build HBase-1.3-JDK8 #373 (See [https://builds.apache.org/job/HBase-1.3-JDK8/373/]) HBASE-18937 Backport HBASE-16815(Low scan ratio in RPC queue tuning (chia7712: rev 1ae312f270c71f7ccbc2c4c8560035e3418ccc92) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RWQueueRpcExecutor.java > Backport HBASE-16815 to branch-1.3 > -- > > Key: HBASE-18937 > URL: https://issues.apache.org/jira/browse/HBASE-18937 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1 >Reporter: Ashish Singhi >Assignee: Ashish Singhi > Fix For: 1.3.2 > > Attachments: HBASE-18937-branch-1.3.patch, > HBASE-18937-branch-1.3.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18626) Handle the incompatible change about the replication TableCFs' config
[ https://issues.apache.org/jira/browse/HBASE-18626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258368#comment-16258368 ] Guanghao Zhang commented on HBASE-18626: Ping [~andrew.purt...@gmail.com] [~busbey] for reviewing. > Handle the incompatible change about the replication TableCFs' config > - > > Key: HBASE-18626 > URL: https://issues.apache.org/jira/browse/HBASE-18626 > Project: HBase > Issue Type: Bug >Affects Versions: 3.0.0, 1.4.0, 1.5.0, 2.0.0-alpha-3 >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Attachments: HBASE-18626.branch-1.001.patch > > > About compatibility, there is one incompatible change about the replication > TableCFs' config. The old config is a string and it concatenate the list of > tables and column families in format "table1:cf1,cf2;table2:cfA,cfB" in > zookeeper for table-cf to replication peer mapping. When parse the config, it > use ":" to split the string. If table name includes namespace, it will be > wrong (See HBASE-11386). It is a problem since we support namespace (0.98). > So HBASE-11393 (and HBASE-16653) changed it to a PB object. When rolling > update cluster, you need rolling master first. And the master will try to > translate the string config to a PB object. But there are two problems. > 1. Permission problem. The replication client can write the zookeeper > directly. So the znode may have different owner. And master may don't have > the write permission for the znode. It maybe failed to translate old > table-cfs string to new PB Object. See HBASE-16938 > 2. We usually keep compatibility between old client and new server. But the > old replication client may write a string config to znode directly. Then the > new server can't parse them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18937) Backport HBASE-16815 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258369#comment-16258369 ] Hudson commented on HBASE-18937: FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #353 (See [https://builds.apache.org/job/HBase-1.3-JDK7/353/]) HBASE-18937 Backport HBASE-16815(Low scan ratio in RPC queue tuning (chia7712: rev 1ae312f270c71f7ccbc2c4c8560035e3418ccc92) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RWQueueRpcExecutor.java > Backport HBASE-16815 to branch-1.3 > -- > > Key: HBASE-18937 > URL: https://issues.apache.org/jira/browse/HBASE-18937 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1 >Reporter: Ashish Singhi >Assignee: Ashish Singhi > Fix For: 1.3.2 > > Attachments: HBASE-18937-branch-1.3.patch, > HBASE-18937-branch-1.3.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16815) Low scan ratio in RPC queue tuning triggers divide by zero exception
[
https://issues.apache.org/jira/browse/HBASE-16815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258375#comment-16258375
]
Hudson commented on HBASE-16815:
SUCCESS: Integrated in Jenkins build HBase-1.3-IT #293 (See
[https://builds.apache.org/job/HBase-1.3-IT/293/])
HBASE-18937 Backport HBASE-16815(Low scan ratio in RPC queue tuning (chia7712:
rev 1ae312f270c71f7ccbc2c4c8560035e3418ccc92)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RWQueueRpcExecutor.java
> Low scan ratio in RPC queue tuning triggers divide by zero exception
>
>
> Key: HBASE-16815
> URL: https://issues.apache.org/jira/browse/HBASE-16815
> Project: HBase
> Issue Type: Bug
> Components: regionserver, rpc
>Affects Versions: 2.0.0, 1.3.0
>Reporter: Lars George
>Assignee: Guanghao Zhang
> Fix For: 2.0.0, 1.4.0, 1.2.4, 1.1.8
>
> Attachments: HBASE-16815-branch-1.2.patch, HBASE-16815.patch
>
>
> Trying the following settings:
> {noformat}
>
> hbase.ipc.server.callqueue.handler.factor
> 0.5
>
>
> hbase.ipc.server.callqueue.read.ratio
> 0.5
>
>
> hbase.ipc.server.callqueue.scan.ratio
> 0.1
>
> {noformat}
> With 30 default handlers, this means 15 queues. Further, it means 8 write
> queues and 7 read queues. 10% of that is {{0.7}} which is then floor'ed to
> {{0}}. The debug log confirms it, as the tertiary check omits the scan
> details when they are zero:
> {noformat}
> 2016-10-12 12:50:27,305 INFO [main] ipc.SimpleRpcScheduler: Using fifo as
> user call queue, count=15
> 2016-10-12 12:50:27,311 DEBUG [main] ipc.RWQueueRpcExecutor: FifoRWQ.default
> writeQueues=7 writeHandlers=15 readQueues=8 readHandlers=14
> {noformat}
> But the code in {{RWQueueRpcExecutor}} calls {{RpcExecutor.startHandler()}}
> nevertheless and that does this:
> {code}
> for (int i = 0; i < numHandlers; i++) {
> final int index = qindex + (i % qsize);
> String name = "RpcServer." + threadPrefix + ".handler=" +
> handlers.size() + ",queue=" +
> index + ",port=" + port;
> {code}
> The modulo triggers then
> {noformat}
> 2016-10-12 11:41:22,810 ERROR [main] master.HMasterCommandLine: Master exiting
> java.lang.RuntimeException: Failed construction of Master: class
> org.apache.hadoop.hbase.master.HMasterCommandLine$LocalHMaster
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.createMasterThread(JVMClusterUtil.java:145)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.addMaster(LocalHBaseCluster.java:220)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.(LocalHBaseCluster.java:155)
> at
> org.apache.hadoop.hbase.master.HMasterCommandLine.startMaster(HMasterCommandLine.java:222)
> at
> org.apache.hadoop.hbase.master.HMasterCommandLine.run(HMasterCommandLine.java:137)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
> at
> org.apache.hadoop.hbase.util.ServerCommandLine.doMain(ServerCommandLine.java:126)
> at org.apache.hadoop.hbase.master.HMaster.main(HMaster.java:2524)
> Caused by: java.lang.ArithmeticException: / by zero
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.startHandlers(RpcExecutor.java:125)
> at
> org.apache.hadoop.hbase.ipc.RWQueueRpcExecutor.startHandlers(RWQueueRpcExecutor.java:178)
> at org.apache.hadoop.hbase.ipc.RpcExecutor.start(RpcExecutor.java:78)
> at
> org.apache.hadoop.hbase.ipc.SimpleRpcScheduler.start(SimpleRpcScheduler.java:272)
> at org.apache.hadoop.hbase.ipc.RpcServer.start(RpcServer.java:2212)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.start(RSRpcServices.java:1143)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.(HRegionServer.java:615)
> at org.apache.hadoop.hbase.master.HMaster.(HMaster.java:396)
> at
> org.apache.hadoop.hbase.master.HMasterCommandLine$LocalHMaster.(HMasterCommandLine.java:312)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.createMasterThread(JVMClusterUtil.java:140)
> ... 7 more
> {noformat}
> That causes the server to not even start. I would suggest we either skip the
> {{startHandler()}} call altogether, or make it zero aware.
> Another possible option is to reserve at least _one_ scan handler/queue when
> the scan ratio is greater than zero, but only of there is more than one read
> handler/queue to begin with.
[jira] [Commented] (HBASE-18937) Backport HBASE-16815 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258374#comment-16258374 ] Hudson commented on HBASE-18937: SUCCESS: Integrated in Jenkins build HBase-1.3-IT #293 (See [https://builds.apache.org/job/HBase-1.3-IT/293/]) HBASE-18937 Backport HBASE-16815(Low scan ratio in RPC queue tuning (chia7712: rev 1ae312f270c71f7ccbc2c4c8560035e3418ccc92) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/RWQueueRpcExecutor.java > Backport HBASE-16815 to branch-1.3 > -- > > Key: HBASE-18937 > URL: https://issues.apache.org/jira/browse/HBASE-18937 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1 >Reporter: Ashish Singhi >Assignee: Ashish Singhi > Fix For: 1.3.2 > > Attachments: HBASE-18937-branch-1.3.patch, > HBASE-18937-branch-1.3.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18937) Backport HBASE-16815 to branch-1.3
[
https://issues.apache.org/jira/browse/HBASE-18937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258364#comment-16258364
]
Chia-Ping Tsai commented on HBASE-18937:
{code}
14:43:15 | Vote | Subsystem | Runtime | Comment
14:43:15
14:43:15 | | || Prechecks
14:43:15 | +1 | hbaseanti | 0m 0s | Patch does not have any
anti-patterns.
14:43:15 | +1 |@author | 0m 0s | The patch does not contain any
@author
14:43:15 | | || tags.
14:43:15 | -1 | test4tests | 0m 0s | The patch doesn't appear to
include any
14:43:15 | | || new or modified tests. Please
justify
14:43:15 | | || why no new tests are needed
for this
14:43:15 | | || patch. Also please list what
manual
14:43:15 | | || steps were performed to verify
this
14:43:15 | | || patch.
14:43:15 | | || branch-1.3 Compile Tests
14:43:15 | +1 | mvninstall | 1m 52s | branch-1.3 passed
14:43:15 | +1 |compile | 0m 33s | branch-1.3 passed
14:43:15 | +1 | checkstyle | 1m 18s | branch-1.3 passed
14:43:15 | +1 | findbugs | 1m 37s | branch-1.3 passed
14:43:15 | +1 |javadoc | 0m 54s | branch-1.3 passed
14:43:15 | | || Patch Compile Tests
14:43:15 | +1 | mvninstall | 0m 46s | the patch passed
14:43:15 | +1 |compile | 0m 33s | the patch passed
14:43:15 | +1 | javac | 0m 33s | the patch passed
14:43:15 | +1 | checkstyle | 0m 59s | the patch passed
14:43:15 | +1 | whitespace | 0m 0s | The patch has no whitespace
issues.
14:43:15 | +1 |hadoopcheck | 17m 9s | The patch does not cause any
errors
14:43:15 | | || with Hadoop 2.4.0 2.4.1 2.5.0
2.5.1
14:43:15 | | || 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1.
14:43:15 | +1 | findbugs | 1m 45s | the patch passed
14:43:15 | +1 |javadoc | 0m 27s | the patch passed
14:43:15 | | || Other Tests
14:43:16 | -1 | unit | 104m 35s | hbase-server in the patch
failed.
14:43:16 | +1 | asflicense | 0m 38s | The patch does not generate
ASF License
14:43:16 | | || warnings.
14:43:16 | | | 133m 36s |
{code}
The failed ut is {{TestPerColumnFamilyFlush}}. Retrying it is succeed.
+1 and will commit it later.
> Backport HBASE-16815 to branch-1.3
> --
>
> Key: HBASE-18937
> URL: https://issues.apache.org/jira/browse/HBASE-18937
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 1.3.1
>Reporter: Ashish Singhi
>Assignee: Ashish Singhi
> Fix For: 1.3.2
>
> Attachments: HBASE-18937-branch-1.3.patch,
> HBASE-18937-branch-1.3.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19247) [hbase-thirdparty] upgrade to Netty 4.1.17
[ https://issues.apache.org/jira/browse/HBASE-19247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258125#comment-16258125 ] Mike Drob commented on HBASE-19247: --- No, we still have to set the property. > [hbase-thirdparty] upgrade to Netty 4.1.17 > -- > > Key: HBASE-19247 > URL: https://issues.apache.org/jira/browse/HBASE-19247 > Project: HBase > Issue Type: Bug > Components: dependencies, thirdparty >Reporter: Mike Drob >Assignee: Mike Drob > Fix For: thirdparty-1.0.2 > > Attachments: HBASE-19247.addendum.patch, > HBASE-19247.addendum.v2.patch, HBASE-19247.patch > > > Netty has a few newer versions that what we're on. Specifically, there have > been some changes to the native library loading that I think might make our > current relocated usage less terrible. > https://github.com/netty/netty/pull/6884 > https://github.com/netty/netty/pull/7102 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19298) CellScanner should be declared as IA.Public
[
https://issues.apache.org/jira/browse/HBASE-19298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19298:
---
Attachment: HBASE-19298.v0.patch
> CellScanner should be declared as IA.Public
> ---
>
> Key: HBASE-19298
> URL: https://issues.apache.org/jira/browse/HBASE-19298
> Project: HBase
> Issue Type: Task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19298.v0.patch
>
>
> User can create the {{CellScanner}} via IA.Public {{CellUtil}}, hence
> {{CellScanner}} should be IA.Public. However, the {{CellScanner}} is used in
> the server code base so making {{CellScanner}} IA.Public may flaw our HBASE
> in the future. In my opinion, we should introduce the {{ExtendedCellScanner}}
> to replace the {{CellScanner}} for server code.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19298) CellScanner should be declared as IA.Public
[
https://issues.apache.org/jira/browse/HBASE-19298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19298:
---
Status: Patch Available (was: Open)
> CellScanner should be declared as IA.Public
> ---
>
> Key: HBASE-19298
> URL: https://issues.apache.org/jira/browse/HBASE-19298
> Project: HBase
> Issue Type: Task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19298.v0.patch
>
>
> User can create the {{CellScanner}} via IA.Public {{CellUtil}}, hence
> {{CellScanner}} should be IA.Public. However, the {{CellScanner}} is used in
> the server code base so making {{CellScanner}} IA.Public may flaw our HBASE
> in the future. In my opinion, we should introduce the {{ExtendedCellScanner}}
> to replace the {{CellScanner}} for server code.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
