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
Reporter: Himanshu Vashishtha
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
