[
https://issues.apache.org/jira/browse/HBASE-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13708061#comment-13708061
]
Lars George commented on HBASE-7035:
------------------------------------
Hey [~akvadrako],
bq. If we just put HTable back into the pool, I think the connection count will
never be reduced, so it will never reach zero and we'll be OK.
Yes, that was my point, since the connection is always used by some tables, we
should be fine.
bq. However, the HTable interface doesn't guarantee thread safety between
scanners, so we can't share them between threads anyway.
That was my earlier point, this does not matter with scanners. You can return
the table to the pool and another thread can use it fine - given only one
thread at a time is using it, and that is guaranteed by the default PoolMap in
HTablePool. The scanner (i.e. ClientScanner instance) is independent and only
shares the connection, which is shared by all tables anyways. Could you
elaborate on where you think this is flawed?
> 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
