[
https://issues.apache.org/jira/browse/HBASE-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13708337#comment-13708337
]
Lars George commented on HBASE-7035:
------------------------------------
But this does point me to the actual pool size settings:
{code}
ThriftHBaseServiceHandler(Configuration conf) {
htablePool = new HTablePool(conf, Integer.MAX_VALUE);
}
{code}
which means it is pretty much unbound. That seems wrong too. I create
HBASE-8948 to track that separately.
> thrift server closes HTable of open Scanners
> --------------------------------------------
>
> Key: HBASE-7035
> URL: https://issues.apache.org/jira/browse/HBASE-7035
> Project: HBase
> Issue Type: Sub-task
> Components: Thrift
> Affects Versions: 0.94.4
> Reporter: Devin Bayer
> Labels: thrift2
> Attachments: old-hbase-thrift-v1.patch
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> ThriftHBaseServiceHandler.openScanner() does this:
> 1. table = pool.getTable()
> 2. scanner = table.getScanner()
> 3. table.close()
> 4. return scanner
> While back porting the thrift server to 0.92.6, I found that table.close()
> calls connection.close(). Further calls to scanner.next() raise a
> ConnectionClosed exception. The unit tests do not catch this since they reuse
> an open HConnection instance.
> This might work on trunk, but depends on the implementations of HTablePool,
> HTable and HConnectionManager. Even with the pool wrapper, if the pool is
> full, table.close() may be called, which may invalidate the table. Also,
> HTable is not thread-safe, but they are being reused since they go back in
> the pool.
> I suggest storing the table handle along with the scanner.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
