Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 17 Jul 2013 08:00:55 +0000 (UTC)
From: "Lars George (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12613117.1350984409267.64144.1374048055094@arcas>
In-Reply-To: <JIRA.12613117.1350984409267@arcas>
References: <JIRA.12613117.1350984409267@arcas>
Subject: [jira] [Commented] (HBASE-7035) thrift server closes HTable of open
 Scanners
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13710835#comment-13710835 ] 

Lars George commented on HBASE-7035:
------------------------------------

I tried to figure what the status quo is here and did create a test app (https://github.com/larsgeorge/hbase-scanner-test), which simulates the discussed issue. I am testing this on 0.94 to see what happens from there on out. So I found that it is pretty much impossible to close the connection, since there are many classes holding a reference to it. It is also unlikely that you have a separate config instance and therefore cause a second connection to be tracked. 

Also, as suspected, scans do *not* share anything with the table instance they were created from, besides the connection. So while it is possible to close the table and reduce the reference counter, it is unlikely for the above reasons (and testing) that this causes issues. Since they only share the connection, ResultScanners are thread-safe (go figure).

I am closing this issue for now as not relevant, please reopen if someone feels I missed something.
                
> 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