hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3553) number of active threads in HTable's ThreadPoolExecutor
Date Fri, 25 Feb 2011 02:52:40 GMT

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

Hudson commented on HBASE-3553:
-------------------------------

Integrated in HBase-TRUNK #1751 (See [https://hudson.apache.org/hudson/job/HBase-TRUNK/1751/])
    HBASE-3553  Make HTable ThreadPoolExecutor actually launch up to max threads


> number of active threads in HTable's ThreadPoolExecutor
> -------------------------------------------------------
>
>                 Key: HBASE-3553
>                 URL: https://issues.apache.org/jira/browse/HBASE-3553
>             Project: HBase
>          Issue Type: Improvement
>          Components: client
>    Affects Versions: 0.90.1
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>             Fix For: 0.90.2
>
>         Attachments: HBASE-3553_final.patch, ThreadPoolTester.java, benchmark_results.txt
>
>
> Using a ThreadPoolExecutor with corePoolSize = 0 and using LinkedBlockingQueue as the
collection to hold incoming runnable tasks seems to be having the effect of running only 1
thread, irrespective of the maxpoolsize set by reading the property hbase.htable.threads.max
(or number of RS). (This is what I infer from reading source code of ThreadPoolExecutor class
in 1.6)
> On a 3 node ec2 cluster, a full table scan with approx 9m rows results in almost similar
timing with a sequential scanner (240 secs) and scanning with a Coprocessor (230 secs), that
uses HTable's pool to  submit callable objects for each region. 
> I try to come up with a test class that creates a similar threadpool, and test that whether
the pool size ever grows beyond 1. It also confirms that it remains 1 though it executed 100
requests.
> It seems the desired behavior was to release all resources when the client is done reading,
but this can be achieved by setting allowCoreThreadTimeOut to true (after setting a +ve corePoolSize).

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message