[jira] [Commented] (HBASE-15784) Misuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/HBASE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15288893#comment-15288893 ] Hudson commented on HBASE-15784: FAILURE: Integrated in HBase-Trunk_matrix #928 (See [https://builds.apache.org/job/HBase-Trunk_matrix/928/]) HBASE-15784 Misuse core/maxPoolSize of LinkedBlockingQueue in (ramkrishna: rev 7b5d5394c08e4d5a18c8f9fc62b45930bf892f41) * hbase-server/src/test/resources/hbase-site.xml * hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsckReplicas.java * hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/TBoundedThreadPoolServer.java * hbase-client/src/test/resources/hbase-site.xml * hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionImplementation.java * hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/HFileReplicator.java * hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift/ThriftServerRunner.java * hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsckTwoRS.java * hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsckMOB.java * hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/RegionReplicaReplicationEndpoint.java * hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsckOneRS.java * hbase-server/src/main/java/org/apache/hadoop/hbase/util/MultiHConnection.java > Misuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor > > > Key: HBASE-15784 > URL: https://issues.apache.org/jira/browse/HBASE-15784 > Project: HBase > Issue Type: Bug > Components: Client, Replication, Thrift >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Fix For: 2.0.0 > > Attachments: HBASE-15784-v2.patch, HBASE-15784.patch > > > LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the > thread pool not to be blocked if the number of running threads in the pool is > less than the max pool size and the queue is not full. > But when the core pool size of ThreadPoolExecutor is different from the max > pool size, the things don't go as expected. When the number of running > threads is the same with the core size, more requests of executions are added > into the LinkedBlockingQueue. And the requests can be executed again only > when LinkedBlockingQueue is full or some of running threads are finished. > Thus it is better to use the same value for the core and max pool size when > the LinkedBlockingQueue is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15784) Misuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/HBASE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15288531#comment-15288531 ] Jingcheng Du commented on HBASE-15784: -- Thanks Ram, I've updated the release notes for this. > Misuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor > > > Key: HBASE-15784 > URL: https://issues.apache.org/jira/browse/HBASE-15784 > Project: HBase > Issue Type: Bug > Components: Client, Replication, Thrift >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-15784-v2.patch, HBASE-15784.patch > > > LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the > thread pool not to be blocked if the number of running threads in the pool is > less than the max pool size and the queue is not full. > But when the core pool size of ThreadPoolExecutor is different from the max > pool size, the things don't go as expected. When the number of running > threads is the same with the core size, more requests of executions are added > into the LinkedBlockingQueue. And the requests can be executed again only > when LinkedBlockingQueue is full or some of running threads are finished. > Thus it is better to use the same value for the core and max pool size when > the LinkedBlockingQueue is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15784) Misuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/HBASE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15288528#comment-15288528 ] ramkrishna.s.vasudevan commented on HBASE-15784: +1 for commit. Since the exposed config is removed should it be specified in release notes? > Misuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor > > > Key: HBASE-15784 > URL: https://issues.apache.org/jira/browse/HBASE-15784 > Project: HBase > Issue Type: Bug > Components: Client, Replication, Thrift >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-15784-v2.patch, HBASE-15784.patch > > > LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the > thread pool not to be blocked if the number of running threads in the pool is > less than the max pool size and the queue is not full. > But when the core pool size of ThreadPoolExecutor is different from the max > pool size, the things don't go as expected. When the number of running > threads is the same with the core size, more requests of executions are added > into the LinkedBlockingQueue. And the requests can be executed again only > when LinkedBlockingQueue is full or some of running threads are finished. > Thus it is better to use the same value for the core and max pool size when > the LinkedBlockingQueue is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15784) MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/HBASE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279447#comment-15279447 ] Anoop Sam John commented on HBASE-15784: +1 > MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor > > > Key: HBASE-15784 > URL: https://issues.apache.org/jira/browse/HBASE-15784 > Project: HBase > Issue Type: Bug > Components: Client, Replication, Thrift >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-15784-v2.patch, HBASE-15784.patch > > > LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the > thread pool not to be blocked if the number of running threads in the pool is > less than the max pool size and the queue is not full. > But when the core pool size of ThreadPoolExecutor is different from the max > pool size, the things don't go as expected. When the number of running > threads is the same with the core size, more requests of executions are added > into the LinkedBlockingQueue. And the requests can be executed again only > when LinkedBlockingQueue is full or some of running threads are finished. > Thus it is better to use the same value for the core and max pool size when > the LinkedBlockingQueue is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15784) MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/HBASE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15279444#comment-15279444 ] Jingcheng Du commented on HBASE-15784: -- Any comments for the latest patch? Thanks a lot! > MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor > > > Key: HBASE-15784 > URL: https://issues.apache.org/jira/browse/HBASE-15784 > Project: HBase > Issue Type: Bug > Components: Client, Replication, Thrift >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-15784-v2.patch, HBASE-15784.patch > > > LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the > thread pool not to be blocked if the number of running threads in the pool is > less than the max pool size and the queue is not full. > But when the core pool size of ThreadPoolExecutor is different from the max > pool size, the things don't go as expected. When the number of running > threads is the same with the core size, more requests of executions are added > into the LinkedBlockingQueue. And the requests can be executed again only > when LinkedBlockingQueue is full or some of running threads are finished. > Thus it is better to use the same value for the core and max pool size when > the LinkedBlockingQueue is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15784) MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/HBASE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276048#comment-15276048 ] Jingcheng Du commented on HBASE-15784: -- Thanks! Added the comments. > MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor > > > Key: HBASE-15784 > URL: https://issues.apache.org/jira/browse/HBASE-15784 > Project: HBase > Issue Type: Bug > Components: Client, Replication, Thrift >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-15784-v2.patch, HBASE-15784.patch > > > LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the > thread pool not to be blocked if the number of running threads in the pool is > less than the max pool size and the queue is not full. > But when the core pool size of ThreadPoolExecutor is different from the max > pool size, the things don't go as expected. When the number of running > threads is the same with the core size, more requests of executions are added > into the LinkedBlockingQueue. And the requests can be executed again only > when LinkedBlockingQueue is full or some of running threads are finished. > Thus it is better to use the same value for the core and max pool size when > the LinkedBlockingQueue is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15784) MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/HBASE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15274073#comment-15274073 ] Ted Yu commented on HBASE-15784: Please add release note since some config parameter, such as hbase.hconnection.threads.core , wouldn't be used any more. > MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor > > > Key: HBASE-15784 > URL: https://issues.apache.org/jira/browse/HBASE-15784 > Project: HBase > Issue Type: Bug > Components: Client, Replication, Thrift >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-15784-v2.patch, HBASE-15784.patch > > > LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the > thread pool not to be blocked if the number of running threads in the pool is > less than the max pool size and the queue is not full. > But when the core pool size of ThreadPoolExecutor is different from the max > pool size, the things don't go as expected. When the number of running > threads is the same with the core size, more requests of executions are added > into the LinkedBlockingQueue. And the requests can be executed again only > when LinkedBlockingQueue is full or some of running threads are finished. > Thus it is better to use the same value for the core and max pool size when > the LinkedBlockingQueue is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15784) MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
[
https://issues.apache.org/jira/browse/HBASE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273964#comment-15273964
]
Hadoop QA commented on HBASE-15784:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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 6 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 26s
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 3s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 34s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
5s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
18s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 3s
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 57s
{color} | {color:green} master passed with JDK v1.7.0_79 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
53s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 24s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 24s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 32s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 32s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
53s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 1s
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
11m 23s {color} | {color:green} Patch does not cause any errors with Hadoop
2.4.1 2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 8s
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 59s
{color} | {color:green} the patch passed with JDK v1.7.0_79 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 9s
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 132m 29s
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 42s
{color} | {color:green} hbase-thrift in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
41s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 195m 56s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12802635/HBASE-15784-v2.patch |
| JIRA Issue | HBASE-15784 |
| Optional Tests |
[jira] [Commented] (HBASE-15784) MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/HBASE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273849#comment-15273849 ] Jingcheng Du commented on HBASE-15784: -- Checked the hbase book, nothing needs to be changed. > MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor > > > Key: HBASE-15784 > URL: https://issues.apache.org/jira/browse/HBASE-15784 > Project: HBase > Issue Type: Bug > Components: Client, Replication, Thrift >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-15784-v2.patch, HBASE-15784.patch > > > LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the > thread pool not to be blocked if the number of running threads in the pool is > less than the max pool size and the queue is not full. > But when the core pool size of ThreadPoolExecutor is different from the max > pool size, the things don't go as expected. When the number of running > threads is the same with the core size, more requests of executions are added > into the LinkedBlockingQueue. And the requests can be executed again only > when LinkedBlockingQueue is full or some of running threads are finished. > Thus it is better to use the same value for the core and max pool size when > the LinkedBlockingQueue is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15784) MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/HBASE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273839#comment-15273839 ] Jingcheng Du commented on HBASE-15784: -- bq. Better change this method signature itself to avoid one param.. just pass maxThreads. Similar in other classes also.. This will make sure that later, in same class, no one will do the same mistake again. These methods allow users to pass in a queue instead of LinkedBlockingQueue, and SynchronousQueue doesn't have such an issue. And in these methods of the patch, the core pool size is set as max pool size if LinkedBlockingQueue is used. I think it is okay to keep the same method signature? bq. Pls see whether any of the removed configs mentioned in habse book as well. If so we have to clear those as well. Got it. I will check it. bq. So now we will have much more number of threads initially after the process is started. (As core size is same as max size).. After the time out period many of the threads will get died. The pool starts a thread only when the execution is requested. And the pool allows the core threads to die when timeout if allowCoreThreadTimeOut is set as true. I think the number of threads should be okay if the number of requests is moderate. > MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor > > > Key: HBASE-15784 > URL: https://issues.apache.org/jira/browse/HBASE-15784 > Project: HBase > Issue Type: Bug > Components: Client, Replication, Thrift >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-15784-v2.patch, HBASE-15784.patch > > > LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the > thread pool not to be blocked if the number of running threads in the pool is > less than the max pool size and the queue is not full. > But when the core pool size of ThreadPoolExecutor is different from the max > pool size, the things don't go as expected. When the number of running > threads is the same with the core size, more requests of executions are added > into the LinkedBlockingQueue. And the requests can be executed again only > when LinkedBlockingQueue is full or some of running threads are finished. > Thus it is better to use the same value for the core and max pool size when > the LinkedBlockingQueue is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15784) MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/HBASE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273786#comment-15273786 ] Anoop Sam John commented on HBASE-15784: bq.getThreadPool(int maxThreads, int coreThreads, Better change this method signature itself to avoid one param.. just pass maxThreads. Similar in other classes also.. This will make sure that later, in same class, no one will do the same mistake again. Pls see whether any of the removed configs mentioned in habse book as well. If so we have to clear those as well. So now we will have much more number of threads initially after the process is started. (As core size is same as max size).. After the time out period many of the threads will get died. > MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor > > > Key: HBASE-15784 > URL: https://issues.apache.org/jira/browse/HBASE-15784 > Project: HBase > Issue Type: Bug > Components: Client, Replication, Thrift >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-15784-v2.patch, HBASE-15784.patch > > > LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the > thread pool not to be blocked if the number of running threads in the pool is > less than the max pool size and the queue is not full. > But when the core pool size of ThreadPoolExecutor is different from the max > pool size, the things don't go as expected. When the number of running > threads is the same with the core size, more requests of executions are added > into the LinkedBlockingQueue. And the requests can be executed again only > when LinkedBlockingQueue is full or some of running threads are finished. > Thus it is better to use the same value for the core and max pool size when > the LinkedBlockingQueue is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15784) MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/HBASE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273769#comment-15273769 ] Duo Zhang commented on HBASE-15784: --- Good. I have no other concerns then. > MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor > > > Key: HBASE-15784 > URL: https://issues.apache.org/jira/browse/HBASE-15784 > Project: HBase > Issue Type: Bug > Components: Client, Replication, Thrift >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-15784.patch > > > LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the > thread pool not to be blocked if the number of running threads in the pool is > less than the max pool size and the queue is not full. > But when the core pool size of ThreadPoolExecutor is different from the max > pool size, the things don't go as expected. When the number of running > threads is the same with the core size, more requests of executions are added > into the LinkedBlockingQueue. And the requests can be executed again only > when LinkedBlockingQueue is full or some of running threads are finished. > Thus it is better to use the same value for the core and max pool size when > the LinkedBlockingQueue is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15784) MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/HBASE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273767#comment-15273767 ] Jingcheng Du commented on HBASE-15784: -- bq. And I suggest to set allowCoreThreadTimeOut to true. The patch only shows diff so I'm not sure whether we set it at all places. Could you please verify it? Thanks for comments. All of the pools have been set allowCoreThreadTimeOut as true. > MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor > > > Key: HBASE-15784 > URL: https://issues.apache.org/jira/browse/HBASE-15784 > Project: HBase > Issue Type: Bug > Components: Client, Replication, Thrift >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-15784.patch > > > LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the > thread pool not to be blocked if the number of running threads in the pool is > less than the max pool size and the queue is not full. > But when the core pool size of ThreadPoolExecutor is different from the max > pool size, the things don't go as expected. When the number of running > threads is the same with the core size, more requests of executions are added > into the LinkedBlockingQueue. And the requests can be executed again only > when LinkedBlockingQueue is full or some of running threads are finished. > Thus it is better to use the same value for the core and max pool size when > the LinkedBlockingQueue is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15784) MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/HBASE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273760#comment-15273760 ] Duo Zhang commented on HBASE-15784: --- Yes, ThreadPoolExecutor only adds new threads when queue full if we already have more threads than core pool size. +1 on setting core pool size to a value same with max pool size. And I suggest to set allowCoreThreadTimeOut to true. The patch only shows diff so I'm not sure whether we set it at all places. Could you please verify it? Thanks. > MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor > > > Key: HBASE-15784 > URL: https://issues.apache.org/jira/browse/HBASE-15784 > Project: HBase > Issue Type: Bug > Components: Client, Replication, Thrift >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-15784.patch > > > LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the > thread pool not to be blocked if the number of running threads in the pool is > less than the max pool size and the queue is not full. > But when the core pool size of ThreadPoolExecutor is different from the max > pool size, the things don't go as expected. When the number of running > threads is the same with the core size, more requests of executions are added > into the LinkedBlockingQueue. And the requests can be executed again only > when LinkedBlockingQueue is full or some of running threads are finished. > Thus it is better to use the same value for the core and max pool size when > the LinkedBlockingQueue is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
