It just seems like the auto scaling ThreadPoolExecutor will do a pretty good job of scaling up and down the threads as they are needed (we're already doing that right now the only difference would be the core pool threads would be shared). If things are way off then the user can pass in their own. This seems like a case of making the beginner user pay the cost of an advanced feature.
On Tue, Apr 2, 2013 at 6:16 PM, lars hofhansl <[email protected]> wrote: > I think it'd make it hard to size the pool correctly. > There is a proposed patch here: > https://issues.apache.org/jira/browse/HBASE-6580 where we'd tie the > threadpool to an HConnection, I think that would be the correct going > forward. > > -- Lars > > > > ________________________________ > From: Elliott Clark <[email protected]> > To: "[email protected]" <[email protected]> > Sent: Tuesday, April 2, 2013 3:44 PM > Subject: Shared ThreadPoolExecutor in HTable by default. > > Is there any reason that the ThreadPoolExecutor used in HTable[1] couldn't > be a singleton. That would mean that by default htables share threads (as I > would argue is correct), but still give advanced users the ability to > override this using the more explicit[2] constructor. > > > 1. > > https://github.com/apache/hbase/blob/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java#L183 > 2. > > https://github.com/apache/hbase/blob/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java#L202 > > Thanks >
