[
https://issues.apache.org/jira/browse/HBASE-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707828#comment-13707828
]
Lars George commented on HBASE-7035:
------------------------------------
Connections are reference counted, see
[HConnectionManager|https://github.com/apache/hbase/blob/0.94/src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java#L296]
for reference. So given the issues we had with connection identities in there
are fixed, we should be OK to close a table as the connection will be counted
down? But then the scanner is a non-counted reference, but only when all tables
are closed and the reference count ends up being zero it gets really closed. By
that time scanners should be all done?
The other option we discussed is to hold on to the table for the scanner, but
then we have one for every instance, which is way too much under load. We only
need to hold on to one per table, therefore keeping the umbilical cord alive
(so to speak).
> 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
