[
https://issues.apache.org/jira/browse/HBASE-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855933#action_12855933
]
Bogdan DRAGU commented on HBASE-2393:
-------------------------------------
Ok. I realize now I wasn't very accurate. I was thinking on a per thread basis.
Yes, for 100 tables the maximum number of construct calls would be
100*num_threads.
The problem I see with using HTablePool in ThriftServer is that it is based on
a getTable-putTable approach. One gets an HTable instance using getTable (which
removes it from the pool so no other thread can use it) and has to put it back
in using putTable when he's done with it. While we know when to remove the
table from the pool in the ThriftServer (evidently, when THriftServer.getTable
is called), we currently have no way of determining when the caller is done
with it so we could put it back in.
> ThriftServer instantiates a new HTable per request
> --------------------------------------------------
>
> Key: HBASE-2393
> URL: https://issues.apache.org/jira/browse/HBASE-2393
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: thrift
> Affects Versions: 0.21.0
> Reporter: Jean-Daniel Cryans
> Assignee: Bogdan DRAGU
> Fix For: 0.20.5, 0.21.0
>
> Attachments: hbase-2393.patch
>
>
> Every request creates a new HTable in ThriftServer, this is highly
> inefficient. It's even worse now that the HTable constructor does a RPC to
> the master.
> Assigning to Cosmin since he said they have some code they can share.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
