[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[ https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270246#comment-14270246 ] Hudson commented on HBASE-12071: SUCCESS: Integrated in HBase-1.0 #643 (See [https://builds.apache.org/job/HBase-1.0/643/]) HBASE-12071 Separate out thread pool for Master - RegionServer communication (Stephen Yuan Jiang) (ndimiduk: rev bfc0c74cbabb97955b1355fb921f2f05a9fe972b) * hbase-protocol/src/main/protobuf/RPC.proto * hbase-client/src/main/java/org/apache/hadoop/hbase/HRegionInfo.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/SimpleRpcScheduler.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestPriorityRpc.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/SimpleRpcSchedulerFactory.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/AnnotationReadingPriorityFunction.java * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/RPCProtos.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestQosFunction.java * hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java * hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/PayloadCarryingRpcController.java Separate out thread pool for Master - RegionServer communication -- Key: HBASE-12071 URL: https://issues.apache.org/jira/browse/HBASE-12071 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0, 1.1.0 Reporter: Sudarshan Kadambi Assignee: Stephen Yuan Jiang Labels: reliablity Fix For: 1.0.0, 2.0.0, 1.1.0 Attachments: 0001-HBASE-12071-Separate-out-thread-pool-for-Master-Regi.patch, HBASE-12071.v1-branch-1.patch, HBASE-12071.v2-master.patch, HBASE-12071.v2-master.patch, HBASE-12071.v3-master.patch, HBASE-12071.v4-master.patch, HBASE-12071.v5-master.patch Over in HBASE-12028, there is a discussion about the case of a RegionServer still being alive despite all its handler threads being dead. One outcome of this is that the Master is left hanging on the RS for completion of various operations - such as region un-assignment when a table is disabled. Does it make sense to create a separate thread pool for communication between the Master and the RS? This addresses not just the case of the RPC handler threads terminating but also long-running queries or co-processor executions holding up master operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[ https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270251#comment-14270251 ] Hudson commented on HBASE-12071: SUCCESS: Integrated in HBase-1.1 #68 (See [https://builds.apache.org/job/HBase-1.1/68/]) HBASE-12071 Separate out thread pool for Master - RegionServer communication (Stephen Yuan Jiang) (ndimiduk: rev 240ef1235843a54a005bbd62a3e7228a63db218f) * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestPriorityRpc.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestQosFunction.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java * hbase-protocol/src/main/protobuf/RPC.proto * hbase-client/src/main/java/org/apache/hadoop/hbase/HRegionInfo.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/SimpleRpcScheduler.java * hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java * hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/PayloadCarryingRpcController.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/SimpleRpcSchedulerFactory.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/AnnotationReadingPriorityFunction.java * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/RPCProtos.java Separate out thread pool for Master - RegionServer communication -- Key: HBASE-12071 URL: https://issues.apache.org/jira/browse/HBASE-12071 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0, 1.1.0 Reporter: Sudarshan Kadambi Assignee: Stephen Yuan Jiang Labels: reliablity Fix For: 1.0.0, 2.0.0, 1.1.0 Attachments: 0001-HBASE-12071-Separate-out-thread-pool-for-Master-Regi.patch, HBASE-12071.v1-branch-1.patch, HBASE-12071.v2-master.patch, HBASE-12071.v2-master.patch, HBASE-12071.v3-master.patch, HBASE-12071.v4-master.patch, HBASE-12071.v5-master.patch Over in HBASE-12028, there is a discussion about the case of a RegionServer still being alive despite all its handler threads being dead. One outcome of this is that the Master is left hanging on the RS for completion of various operations - such as region un-assignment when a table is disabled. Does it make sense to create a separate thread pool for communication between the Master and the RS? This addresses not just the case of the RPC handler threads terminating but also long-running queries or co-processor executions holding up master operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[ https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270275#comment-14270275 ] Hudson commented on HBASE-12071: SUCCESS: Integrated in HBase-TRUNK #6006 (See [https://builds.apache.org/job/HBase-TRUNK/6006/]) HBASE-12071 Separate out thread pool for Master - RegionServer communication (Stephen Yuan Jiang) (ndimiduk: rev dde713ee4e7845a1bd272b1c318ba0af08577e4d) * hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/PayloadCarryingRpcController.java * hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/SimpleRpcScheduler.java * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/RPCProtos.java * hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java * hbase-client/src/main/java/org/apache/hadoop/hbase/HRegionInfo.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/SimpleRpcSchedulerFactory.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestQosFunction.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/AnnotationReadingPriorityFunction.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestPriorityRpc.java * hbase-protocol/src/main/protobuf/RPC.proto Separate out thread pool for Master - RegionServer communication -- Key: HBASE-12071 URL: https://issues.apache.org/jira/browse/HBASE-12071 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0, 1.1.0 Reporter: Sudarshan Kadambi Assignee: Stephen Yuan Jiang Labels: reliablity Fix For: 1.0.0, 2.0.0, 1.1.0 Attachments: 0001-HBASE-12071-Separate-out-thread-pool-for-Master-Regi.patch, HBASE-12071.v1-branch-1.patch, HBASE-12071.v2-master.patch, HBASE-12071.v2-master.patch, HBASE-12071.v3-master.patch, HBASE-12071.v4-master.patch, HBASE-12071.v5-master.patch Over in HBASE-12028, there is a discussion about the case of a RegionServer still being alive despite all its handler threads being dead. One outcome of this is that the Master is left hanging on the RS for completion of various operations - such as region un-assignment when a table is disabled. Does it make sense to create a separate thread pool for communication between the Master and the RS? This addresses not just the case of the RPC handler threads terminating but also long-running queries or co-processor executions holding up master operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[ https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14268567#comment-14268567 ] Enis Soztutar commented on HBASE-12071: --- +1. Separate out thread pool for Master - RegionServer communication -- Key: HBASE-12071 URL: https://issues.apache.org/jira/browse/HBASE-12071 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0, 1.1.0 Reporter: Sudarshan Kadambi Assignee: Stephen Yuan Jiang Labels: reliablity Fix For: 1.0.0, 2.0.0, 1.1.0 Attachments: HBASE-12071.v1-branch-1.patch, HBASE-12071.v2-master.patch, HBASE-12071.v2-master.patch, HBASE-12071.v3-master.patch, HBASE-12071.v4-master.patch, HBASE-12071.v5-master.patch Over in HBASE-12028, there is a discussion about the case of a RegionServer still being alive despite all its handler threads being dead. One outcome of this is that the Master is left hanging on the RS for completion of various operations - such as region un-assignment when a table is disabled. Does it make sense to create a separate thread pool for communication between the Master and the RS? This addresses not just the case of the RPC handler threads terminating but also long-running queries or co-processor executions holding up master operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[ https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14268425#comment-14268425 ] Nick Dimiduk commented on HBASE-12071: -- [~enis], [~apurtell] you guys good with this patch? I can get it committed before things rot. Is this viable for 0.98 backport? Will this step on Phoenix toes? Separate out thread pool for Master - RegionServer communication -- Key: HBASE-12071 URL: https://issues.apache.org/jira/browse/HBASE-12071 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0, 1.1.0 Reporter: Sudarshan Kadambi Assignee: Stephen Yuan Jiang Labels: reliablity Fix For: 2.0.0, 1.1.0 Attachments: HBASE-12071.v1-branch-1.patch, HBASE-12071.v2-master.patch, HBASE-12071.v2-master.patch, HBASE-12071.v3-master.patch, HBASE-12071.v4-master.patch, HBASE-12071.v5-master.patch Over in HBASE-12028, there is a discussion about the case of a RegionServer still being alive despite all its handler threads being dead. One outcome of this is that the Master is left hanging on the RS for completion of various operations - such as region un-assignment when a table is disabled. Does it make sense to create a separate thread pool for communication between the Master and the RS? This addresses not just the case of the RPC handler threads terminating but also long-running queries or co-processor executions holding up master operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[
https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14266546#comment-14266546
]
Hadoop QA commented on HBASE-12071:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12690375/HBASE-12071.v1-branch-1.patch
against master branch at commit 26e3e1b300670d6c3f9f4853aa937226592b9537.
ATTACHMENT ID: 12690375
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12333//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12333//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12333//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12333//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12333//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12333//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12333//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12333//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12333//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12333//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12333//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12333//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12333//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12333//console
This message is automatically generated.
Separate out thread pool for Master - RegionServer communication
--
Key: HBASE-12071
URL: https://issues.apache.org/jira/browse/HBASE-12071
Project: HBase
Issue Type: Improvement
Affects Versions: 2.0.0, 1.1.0
Reporter: Sudarshan Kadambi
Assignee: Stephen Yuan Jiang
Labels: reliablity
Fix For: 2.0.0, 1.1.0
Attachments: HBASE-12071.v1-branch-1.patch,
HBASE-12071.v2-master.patch, HBASE-12071.v2-master.patch,
HBASE-12071.v3-master.patch, HBASE-12071.v4-master.patch,
HBASE-12071.v5-master.patch
Over in HBASE-12028, there is a discussion about the case of a RegionServer
still being alive despite all its handler threads being dead. One outcome of
this is that the Master is left hanging on the RS for completion of various
operations - such as region un-assignment when a table is disabled. Does it
make sense to create a separate thread pool for communication between the
Master and the RS? This addresses not just the case of the RPC handler
threads terminating but also long-running queries or co-processor executions
holding up master operations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[
https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14266573#comment-14266573
]
Nick Dimiduk commented on HBASE-12071:
--
What's the thinking on increasing the number of queues to 2?
{noformat}
- this.priorityExecutor =
- priorityHandlerCount 0 ? new BalancedQueueRpcExecutor(Priority,
priorityHandlerCount,
- 1, maxQueueLength, conf, abortable) : null;
+// Create 2 queues to help priorityExecutor be more scalable.
+this.priorityExecutor = priorityHandlerCount 0 ?
+new BalancedQueueRpcExecutor(Priority, priorityHandlerCount, 2,
maxQueueLength) : null;
{noformat}
It's probably worth while turning priority into a protobuf enum. I don't know
if we can do that, given that RequestHeader.priority is already defined as a
uint32. The docs say valid enum value range is 32-bit signed int, so maybe we'd
have to deprecate the existing field? Someone who knows more about protobuf,
any thoughts here?
Other question: can we move the QosPriority annotations over to the
BlockingInterfaces? Maybe not since they're generated protobuf...
Otherwise, +1. You test all this out [~syuanjiang]? Working as expected?
Separate out thread pool for Master - RegionServer communication
--
Key: HBASE-12071
URL: https://issues.apache.org/jira/browse/HBASE-12071
Project: HBase
Issue Type: Improvement
Affects Versions: 2.0.0, 1.1.0
Reporter: Sudarshan Kadambi
Assignee: Stephen Yuan Jiang
Labels: reliablity
Fix For: 2.0.0, 1.1.0
Attachments: HBASE-12071.v1-branch-1.patch,
HBASE-12071.v2-master.patch, HBASE-12071.v2-master.patch,
HBASE-12071.v3-master.patch, HBASE-12071.v4-master.patch,
HBASE-12071.v5-master.patch
Over in HBASE-12028, there is a discussion about the case of a RegionServer
still being alive despite all its handler threads being dead. One outcome of
this is that the Master is left hanging on the RS for completion of various
operations - such as region un-assignment when a table is disabled. Does it
make sense to create a separate thread pool for communication between the
Master and the RS? This addresses not just the case of the RPC handler
threads terminating but also long-running queries or co-processor executions
holding up master operations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[ https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14267170#comment-14267170 ] Stephen Yuan Jiang commented on HBASE-12071: [~ndimiduk] To answer your comments, I increased the queues count to 2 to make it more scalable; this is an arbitrary number, ideally it should be tunable, but I am not going far for now. The major goal is to make admin requests using priorityExecutor - I stepped through the code in debugger and verified the results by running relevant Unit Tests. So funcational-wise, it works as expected. Since I have not run system tests (stress tests), whether this change solves customers problem is unknown. We will run system tests in a late cycle to see the results. At least it will not get worse comparing to pre-change. Separate out thread pool for Master - RegionServer communication -- Key: HBASE-12071 URL: https://issues.apache.org/jira/browse/HBASE-12071 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0, 1.1.0 Reporter: Sudarshan Kadambi Assignee: Stephen Yuan Jiang Labels: reliablity Fix For: 2.0.0, 1.1.0 Attachments: HBASE-12071.v1-branch-1.patch, HBASE-12071.v2-master.patch, HBASE-12071.v2-master.patch, HBASE-12071.v3-master.patch, HBASE-12071.v4-master.patch, HBASE-12071.v5-master.patch Over in HBASE-12028, there is a discussion about the case of a RegionServer still being alive despite all its handler threads being dead. One outcome of this is that the Master is left hanging on the RS for completion of various operations - such as region un-assignment when a table is disabled. Does it make sense to create a separate thread pool for communication between the Master and the RS? This addresses not just the case of the RPC handler threads terminating but also long-running queries or co-processor executions holding up master operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[
https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265453#comment-14265453
]
Nick Dimiduk commented on HBASE-12071:
--
{noformat}
---
hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/RPCProtos.java
+++
hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/RPCProtos.java
{noformat}
Do not make changes to any generated code. Instead, this comment should be
updated in hbase-protocol/src/main/protobuf/RPC.proto and the protobuf files
regenerated.
Separate out thread pool for Master - RegionServer communication
--
Key: HBASE-12071
URL: https://issues.apache.org/jira/browse/HBASE-12071
Project: HBase
Issue Type: Improvement
Affects Versions: 2.0.0
Reporter: Sudarshan Kadambi
Assignee: Stephen Yuan Jiang
Fix For: 2.0.0
Attachments: HBASE-12071.v2-master.patch,
HBASE-12071.v2-master.patch, HBASE-12071.v3-master.patch
Over in HBASE-12028, there is a discussion about the case of a RegionServer
still being alive despite all its handler threads being dead. One outcome of
this is that the Master is left hanging on the RS for completion of various
operations - such as region un-assignment when a table is disabled. Does it
make sense to create a separate thread pool for communication between the
Master and the RS? This addresses not just the case of the RPC handler
threads terminating but also long-running queries or co-processor executions
holding up master operations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[
https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265593#comment-14265593
]
Hadoop QA commented on HBASE-12071:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12690205/HBASE-12071.v3-master.patch
against master branch at commit c348cd327b9ae3635dc9d9360e2c7088976199c0.
ATTACHMENT ID: 12690205
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.TestPriorityRpc
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12317//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12317//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12317//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12317//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12317//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12317//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12317//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12317//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12317//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12317//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12317//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12317//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12317//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12317//console
This message is automatically generated.
Separate out thread pool for Master - RegionServer communication
--
Key: HBASE-12071
URL: https://issues.apache.org/jira/browse/HBASE-12071
Project: HBase
Issue Type: Improvement
Affects Versions: 2.0.0
Reporter: Sudarshan Kadambi
Assignee: Stephen Yuan Jiang
Fix For: 2.0.0
Attachments: HBASE-12071.v2-master.patch,
HBASE-12071.v2-master.patch, HBASE-12071.v3-master.patch,
HBASE-12071.v4-master.patch
Over in HBASE-12028, there is a discussion about the case of a RegionServer
still being alive despite all its handler threads being dead. One outcome of
this is that the Master is left hanging on the RS for completion of various
operations - such as region un-assignment when a table is disabled. Does it
make sense to create a separate thread pool for communication between the
Master and the RS? This addresses not just the case of the RPC handler
threads terminating but also long-running queries or co-processor executions
holding up master operations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[ https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265662#comment-14265662 ] Enis Soztutar commented on HBASE-12071: --- Failing test seems related. Separate out thread pool for Master - RegionServer communication -- Key: HBASE-12071 URL: https://issues.apache.org/jira/browse/HBASE-12071 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Sudarshan Kadambi Assignee: Stephen Yuan Jiang Fix For: 2.0.0 Attachments: HBASE-12071.v2-master.patch, HBASE-12071.v2-master.patch, HBASE-12071.v3-master.patch, HBASE-12071.v4-master.patch Over in HBASE-12028, there is a discussion about the case of a RegionServer still being alive despite all its handler threads being dead. One outcome of this is that the Master is left hanging on the RS for completion of various operations - such as region un-assignment when a table is disabled. Does it make sense to create a separate thread pool for communication between the Master and the RS? This addresses not just the case of the RPC handler threads terminating but also long-running queries or co-processor executions holding up master operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[ https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265682#comment-14265682 ] Stephen Yuan Jiang commented on HBASE-12071: This is due to mock in UT only set the region is meta; and my change is expand from only meta table (isMetaTable) to all system tables, therefore, my change checks isSystemTable. Modify unit test to mock system table and attach V5. Separate out thread pool for Master - RegionServer communication -- Key: HBASE-12071 URL: https://issues.apache.org/jira/browse/HBASE-12071 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Sudarshan Kadambi Assignee: Stephen Yuan Jiang Fix For: 2.0.0 Attachments: HBASE-12071.v2-master.patch, HBASE-12071.v2-master.patch, HBASE-12071.v3-master.patch, HBASE-12071.v4-master.patch, HBASE-12071.v5-master.patch Over in HBASE-12028, there is a discussion about the case of a RegionServer still being alive despite all its handler threads being dead. One outcome of this is that the Master is left hanging on the RS for completion of various operations - such as region un-assignment when a table is disabled. Does it make sense to create a separate thread pool for communication between the Master and the RS? This addresses not just the case of the RPC handler threads terminating but also long-running queries or co-processor executions holding up master operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[
https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265636#comment-14265636
]
Hadoop QA commented on HBASE-12071:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12690216/HBASE-12071.v4-master.patch
against master branch at commit 7774f964e62842806d849cae1a6af830c137d737.
ATTACHMENT ID: 12690216
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.TestPriorityRpc
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12323//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12323//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12323//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12323//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12323//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12323//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12323//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12323//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12323//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12323//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12323//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12323//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12323//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12323//console
This message is automatically generated.
Separate out thread pool for Master - RegionServer communication
--
Key: HBASE-12071
URL: https://issues.apache.org/jira/browse/HBASE-12071
Project: HBase
Issue Type: Improvement
Affects Versions: 2.0.0
Reporter: Sudarshan Kadambi
Assignee: Stephen Yuan Jiang
Fix For: 2.0.0
Attachments: HBASE-12071.v2-master.patch,
HBASE-12071.v2-master.patch, HBASE-12071.v3-master.patch,
HBASE-12071.v4-master.patch
Over in HBASE-12028, there is a discussion about the case of a RegionServer
still being alive despite all its handler threads being dead. One outcome of
this is that the Master is left hanging on the RS for completion of various
operations - such as region un-assignment when a table is disabled. Does it
make sense to create a separate thread pool for communication between the
Master and the RS? This addresses not just the case of the RPC handler
threads terminating but also long-running queries or co-processor executions
holding up master operations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[
https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265741#comment-14265741
]
Hadoop QA commented on HBASE-12071:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12690250/HBASE-12071.v5-master.patch
against master branch at commit 7774f964e62842806d849cae1a6af830c137d737.
ATTACHMENT ID: 12690250
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12325//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12325//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12325//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12325//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12325//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12325//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12325//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12325//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12325//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12325//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12325//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12325//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12325//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12325//console
This message is automatically generated.
Separate out thread pool for Master - RegionServer communication
--
Key: HBASE-12071
URL: https://issues.apache.org/jira/browse/HBASE-12071
Project: HBase
Issue Type: Improvement
Affects Versions: 2.0.0
Reporter: Sudarshan Kadambi
Assignee: Stephen Yuan Jiang
Fix For: 2.0.0
Attachments: HBASE-12071.v2-master.patch,
HBASE-12071.v2-master.patch, HBASE-12071.v3-master.patch,
HBASE-12071.v4-master.patch, HBASE-12071.v5-master.patch
Over in HBASE-12028, there is a discussion about the case of a RegionServer
still being alive despite all its handler threads being dead. One outcome of
this is that the Master is left hanging on the RS for completion of various
operations - such as region un-assignment when a table is disabled. Does it
make sense to create a separate thread pool for communication between the
Master and the RS? This addresses not just the case of the RPC handler
threads terminating but also long-running queries or co-processor executions
holding up master operations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[
https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263320#comment-14263320
]
Hadoop QA commented on HBASE-12071:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12689893/HBASE-12071.v2-master.patch
against master branch at commit 820f629423f21fbd1dcc7a383955443a2595fd5d.
ATTACHMENT ID: 12689893
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12292//console
This message is automatically generated.
Separate out thread pool for Master - RegionServer communication
--
Key: HBASE-12071
URL: https://issues.apache.org/jira/browse/HBASE-12071
Project: HBase
Issue Type: Improvement
Affects Versions: 2.0.0
Reporter: Sudarshan Kadambi
Assignee: Stephen Yuan Jiang
Fix For: 2.0.0
Attachments: HBASE-12071.v2-master.patch, HBASE-12071.v2-master.patch
Over in HBASE-12028, there is a discussion about the case of a RegionServer
still being alive despite all its handler threads being dead. One outcome of
this is that the Master is left hanging on the RS for completion of various
operations - such as region un-assignment when a table is disabled. Does it
make sense to create a separate thread pool for communication between the
Master and the RS? This addresses not just the case of the RPC handler
threads terminating but also long-running queries or co-processor executions
holding up master operations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[ https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263326#comment-14263326 ] Enis Soztutar commented on HBASE-12071: --- [~syuanjiang] do you mind rebasing the patch for master? Separate out thread pool for Master - RegionServer communication -- Key: HBASE-12071 URL: https://issues.apache.org/jira/browse/HBASE-12071 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Sudarshan Kadambi Assignee: Stephen Yuan Jiang Fix For: 2.0.0 Attachments: HBASE-12071.v2-master.patch, HBASE-12071.v2-master.patch Over in HBASE-12028, there is a discussion about the case of a RegionServer still being alive despite all its handler threads being dead. One outcome of this is that the Master is left hanging on the RS for completion of various operations - such as region un-assignment when a table is disabled. Does it make sense to create a separate thread pool for communication between the Master and the RS? This addresses not just the case of the RPC handler threads terminating but also long-running queries or co-processor executions holding up master operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[ https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263313#comment-14263313 ] Enis Soztutar commented on HBASE-12071: --- +1. Will retry hadoopqa. Separate out thread pool for Master - RegionServer communication -- Key: HBASE-12071 URL: https://issues.apache.org/jira/browse/HBASE-12071 Project: HBase Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Sudarshan Kadambi Assignee: Stephen Yuan Jiang Fix For: 2.0.0 Attachments: HBASE-12071.v2-master.patch, HBASE-12071.v2-master.patch Over in HBASE-12028, there is a discussion about the case of a RegionServer still being alive despite all its handler threads being dead. One outcome of this is that the Master is left hanging on the RS for completion of various operations - such as region un-assignment when a table is disabled. Does it make sense to create a separate thread pool for communication between the Master and the RS? This addresses not just the case of the RPC handler threads terminating but also long-running queries or co-processor executions holding up master operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[
https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14249628#comment-14249628
]
Hadoop QA commented on HBASE-12071:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12687695/HBASE-12071.v1-master.patch
against master branch at commit 99a11390b4758c211af04af2ca0696ac6e3e0aeb.
ATTACHMENT ID: 12687695
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. 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:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.TestQosFunction
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12106//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12106//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12106//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12106//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12106//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12106//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12106//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12106//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12106//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12106//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12106//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12106//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12106//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12106//console
This message is automatically generated.
Separate out thread pool for Master - RegionServer communication
--
Key: HBASE-12071
URL: https://issues.apache.org/jira/browse/HBASE-12071
Project: HBase
Issue Type: Improvement
Affects Versions: 2.0.0
Reporter: Sudarshan Kadambi
Assignee: Stephen Yuan Jiang
Fix For: 2.0.0
Attachments: HBASE-12071.v1-master.patch
Over in HBASE-12028, there is a discussion about the case of a RegionServer
still being alive despite all its handler threads being dead. One outcome of
this is that the Master is left hanging on the RS for completion of various
operations - such as region un-assignment when a table is disabled. Does it
make sense to create a separate thread pool for communication between the
Master and the RS? This addresses not just the case of the RPC handler
threads terminating but also long-running queries or co-processor executions
holding up master operations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[
https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14250800#comment-14250800
]
Hadoop QA commented on HBASE-12071:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12687850/HBASE-12071.v2-master.patch
against master branch at commit 6aa8b3727c75bf8578599ec35afcaad245f13e30.
ATTACHMENT ID: 12687850
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/12122//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12122//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12122//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12122//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12122//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12122//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12122//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12122//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12122//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12122//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12122//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/12122//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/12122//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/12122//console
This message is automatically generated.
Separate out thread pool for Master - RegionServer communication
--
Key: HBASE-12071
URL: https://issues.apache.org/jira/browse/HBASE-12071
Project: HBase
Issue Type: Improvement
Affects Versions: 2.0.0
Reporter: Sudarshan Kadambi
Assignee: Stephen Yuan Jiang
Fix For: 2.0.0
Attachments: HBASE-12071.v2-master.patch
Over in HBASE-12028, there is a discussion about the case of a RegionServer
still being alive despite all its handler threads being dead. One outcome of
this is that the Master is left hanging on the RS for completion of various
operations - such as region un-assignment when a table is disabled. Does it
make sense to create a separate thread pool for communication between the
Master and the RS? This addresses not just the case of the RPC handler
threads terminating but also long-running queries or co-processor executions
holding up master operations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[ https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14243672#comment-14243672 ] Stephen Yuan Jiang commented on HBASE-12071: [~apurtell] currently we have 3 RpcExecutor for different request types: - priorityExecutor for meta table request and some admin requests - replicationExecutor for replication requests - callExecutor for normal requests. Each executor used different thread pools. This should be enough to address [~skadambi]'s concern. I went through the Admin.proto and could add more admin requests (master - region server communication) to use priorityExecutor. Separate out thread pool for Master - RegionServer communication -- Key: HBASE-12071 URL: https://issues.apache.org/jira/browse/HBASE-12071 Project: HBase Issue Type: Improvement Reporter: Sudarshan Kadambi Assignee: Stephen Yuan Jiang Over in HBASE-12028, there is a discussion about the case of a RegionServer still being alive despite all its handler threads being dead. One outcome of this is that the Master is left hanging on the RS for completion of various operations - such as region un-assignment when a table is disabled. Does it make sense to create a separate thread pool for communication between the Master and the RS? This addresses not just the case of the RPC handler threads terminating but also long-running queries or co-processor executions holding up master operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12071) Separate out thread pool for Master - RegionServer communication
[ https://issues.apache.org/jira/browse/HBASE-12071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14154050#comment-14154050 ] Andrew Purtell commented on HBASE-12071: Regarding HBASE-12028, I'd say we should abort the RS if a handler thread terminates due to an unhandled throwable, and if so we wouldn't need this. However bq. This addresses [...] but also long-running queries or co-processor executions holding up master operations. True. Separate out thread pool for Master - RegionServer communication -- Key: HBASE-12071 URL: https://issues.apache.org/jira/browse/HBASE-12071 Project: HBase Issue Type: Bug Reporter: Sudarshan Kadambi Over in HBASE-12028, there is a discussion about the case of a RegionServer still being alive despite all its handler threads being dead. One outcome of this is that the Master is left hanging on the RS for completion of various operations - such as region un-assignment when a table is disabled. Does it make sense to create a separate thread pool for communication between the Master and the RS? This addresses not just the case of the RPC handler threads terminating but also long-running queries or co-processor executions holding up master operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
