Description
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).
Attachments
Attachments
Issue Links
- is related to
-
HBASE-4859 Correctly PreWarm HBCK ThreadPool
-
- Closed
-