[
https://issues.apache.org/jira/browse/HBASE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019183#comment-13019183
]
Jean-Daniel Cryans commented on HBASE-3767:
-------------------------------------------
My expectation is that in a long living JVM the HTables are created early
rather than later, for example with our Thrift servers once you served each
table from each thread you already got all your HTables.
In the case of a bulk upload, the processes are usually MR tasks and are short
lived and the HTable is created up front.
bq. If we had oversized TPE it'd grow as servers grew.
It'd actually prefer that to setting the max to CPU times some number. Default
max to 1000 and lower bound at 1?
bq. Aside: Whose idea was the passing of an ExecutorService from HTable down
into HCM for it to use? Thats a little perverse
Your favorite Canadian, guess which one :)
> Cache the number of RS in HTable
> --------------------------------
>
> Key: HBASE-3767
> URL: https://issues.apache.org/jira/browse/HBASE-3767
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 0.90.2
> Reporter: Jean-Daniel Cryans
> Fix For: 0.90.3
>
>
> When creating a new HTable we have to query ZK to learn about the number of
> region servers in the cluster. That is done for every single one of them, I
> think instead we should do it once per JVM and then reuse that number for all
> the others.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
