hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars George (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7035) thrift server closes HTable of open Scanners
Date Sat, 13 Jul 2013 18:41:49 GMT

    [ 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

Mime
View raw message