[
https://issues.apache.org/jira/browse/HBASE-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707811#comment-13707811
]
Lars George commented on HBASE-7035:
------------------------------------
[~madani], I am not sure what you are looking at. HTable has no reference to
any HTablePool instance, so calling HTable.close does not return it to the
pool. There is an internal pool of worker threads handled in HTable.close() but
that is unrelated.
[~akvadrako], I see what you are saying - and of course we need to hold on to
the table instances - either using HTablePool or as Thrift 1 does with our own
list (which you do of sorts).
Your patch does change the behaviour so that when a scanner is opened, the
HTable instance is *not* returned to the pool, but only when you close the
scanner.
The first issue you are describing is that when you return the table, you might
run into the issue that the table is reused although they are not thread safe.
That should not be an issue since you are not using the table anymore, but a
scanner instance. I think the second issue you describe is the problem, i.e.
when a table is closed, the underlying connection is closed possibly, and
therefore leaves the scanner dangling.
I need to look into 0.94, 0.95 and trunk/0.98 to see what the status (as you
and Hamed touch upon above). If we decide to hang on, we could wrap this into
HBASE-3852 which creates a Scanner wrapper, holding a last-used time and the
actual result scanner. We could easily add the table instance there and hold on
to it in one map. Same thing as yours, just a merge.
> 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
