[jira] [Commented] (HBASE-11590) use a specific ThreadPoolExecutor

["stack (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-11590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14791601#comment-14791601 ] 

stack commented on HBASE-11590:
-------------------------------

Should we down the keepalive timeout so it is seconds only?  We have allowCoreThreadTimeOut(true);  Core threads would run up to the max but could also go down to zero as is noted in http://stackoverflow.com/questions/19528304/how-to-get-the-threadpoolexecutor-to-increase-threads-to-max-before-queueing/19528305#19528305  Or the suggestion by Ralph H at answered Oct 23 '13 at 10:15 in the link looks simple (after executing the current reset the core thread size if not enough for current requests).  There is a new answer on the end... with a GPL soln.

> use a specific ThreadPoolExecutor
> ---------------------------------
>
>                 Key: HBASE-11590
>                 URL: https://issues.apache.org/jira/browse/HBASE-11590
>             Project: HBase
>          Issue Type: Bug
>          Components: Client, Performance
>    Affects Versions: 1.0.0, 2.0.0
>            Reporter: Nicolas Liochon
>            Assignee: Nicolas Liochon
>            Priority: Minor
>             Fix For: 2.0.0
>
>         Attachments: tp.patch
>
>
> The JDK TPE creates all the threads in the pool. As a consequence, we create (by default) 256 threads even if we just need a few.
> The attached TPE create threads only if we have something in the queue.
> On a PE test with replica on, it improved the 99 latency percentile by 5%. 
> Warning: there are likely some race conditions, but I'm posting it here because there is may be an implementation available somewhere we can use, or a good reason not to do that. So feedback welcome as usual. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)