hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elliott Clark <ecl...@apache.org>
Subject Re: Shared ThreadPoolExecutor in HTable by default.
Date Wed, 03 Apr 2013 04:28:25 GMT
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 <larsh@apache.org> 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 <eclark@apache.org>
> To: "dev@hbase.apache.org" <dev@hbase.apache.org>
> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message