[ https://issues.apache.org/jira/browse/HBASE-11590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14804478#comment-14804478 ]
stack commented on HBASE-11590: ------------------------------- bq. If we cut down the timeout, it's more or less equivalent of not having a thread pool at all. Well, if a timeout of 1 or 10 seconds, the pool would be in place when we need it... in times of read/write. No hurry [~nkeywal] On the create of one thread too many, I'd not be too worried given we seem to currently create 255 threads too many (smile). > 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)