Details
Description
From some internal discussions at Salesforce we concluded that we need better control over the resources (mostly threads) consumed by HTable when used in a AppServer with many client threads.
Since HTable is not thread safe, the only options are cache them (in a custom thread local or using HTablePool) or to create them on-demand.
I propose a simple change: Add a new constructor to HTable that takes an optional ExecutorService and HConnection instance. That would make HTable a pretty lightweight object and we would manage the ES and HC separately.
I'll upload a patch a soon to get some feedback.
Attachments
Attachments
Issue Links
- is depended upon by
-
HBASE-6580 Deprecate HTablePool in favor of HConnection.getTable(...)
- Closed
- relates to
-
HBASE-4956 Control direct memory buffer consumption by HBaseClient
- Closed
-
HBASE-4787 Make corePool as a configurable parameter in HTable
- Closed
-
HBASE-4970 Add a parameter so that keepAliveTime of Htable thread pool can be changed
- Closed
-
HBASE-4968 Add to troubleshooting workaround for direct buffer oome's.
- Closed
-
HBASE-5084 Allow different HTable instances to share one ExecutorService
- Closed
1.
|
Allow HBaseAdmin to use an existing connection | Closed | Lars Hofhansl | |
2.
|
Better HTable resource consumption in CoprocessorHost | Closed | Unassigned |