hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-3686) ClientScanner skips too many rows on recovery if using scanner caching
Date Fri, 25 Mar 2011 19:57:05 GMT

     [ https://issues.apache.org/jira/browse/HBASE-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

stack updated HBASE-3686:

      Resolution: Fixed
        Assignee: Sean Sechrist
    Hadoop Flags: [Reviewed]
          Status: Resolved  (was: Patch Available)

Committed branch and trunk.  Nice one Sean (Made you a contributor and assigned you this issue)

> ClientScanner skips too many rows on recovery if using scanner caching
> ----------------------------------------------------------------------
>                 Key: HBASE-3686
>                 URL: https://issues.apache.org/jira/browse/HBASE-3686
>             Project: HBase
>          Issue Type: Bug
>          Components: client
>    Affects Versions: 0.89.20100924, 0.90.1
>            Reporter: Sean Sechrist
>            Assignee: Sean Sechrist
>            Priority: Minor
>         Attachments: 3686.patch
> This can cause rows to be lost from a scan.
> See this thread where the issue was brought up: http://search-hadoop.com/m/xITBQ136xGJ1
> If hbase.regionserver.lease.period is higher on the client than the server we can get
this series of events: 
> 1. Client is scanning along happily, and does something slow.
> 2. Scanner times out on region server
> 3. Client calls HTable.ClientScanner.next()
> 4. The region server throws an UnknownScannerException
> 5. Client catches exception and sees that it's not longer then it's hbase.regionserver.lease.period
config, so it doesn't throw a ScannerTimeoutException. Instead, it treats it like a NSRE.
> Right now the workaround is to make sure the configs are consistent. 
> A possible fix would be to use whatever the region server's scanner timeout is, rather
than the local one.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message