[jira] Updated: (HBASE-910) Scanner misses columns / rows when the scanner is obtained durring a memcache flush

["stack (JIRA)" <ji...@apache.org>]

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

stack updated HBASE-910:
------------------------

    Attachment: 910-v2.patch

Adds test to replicate and the the fix.

This turns out to be a case we've handled elsewhere over in compactions.  When we finish a compaction and there are outstanding scanners, we slot the change in Store readers in under the running scanner.  Here, whats happening is that memcache contents are flushed and a new store file is created but outstanding scanners were set up with a memcache scanner only; when the new flush file is added, outstanding scanners are blind to its content -- but not to the fact that the memcache has been rotated out.

I exploited the mechanism that worked for compaction adding in a store file scanner to outstanding scanner when new reader is added.

> Scanner misses columns / rows when the scanner is obtained durring a memcache flush
> -----------------------------------------------------------------------------------
>
>                 Key: HBASE-910
>                 URL: https://issues.apache.org/jira/browse/HBASE-910
>             Project: Hadoop HBase
>          Issue Type: Bug
>          Components: regionserver
>         Environment: latest trunk
>            Reporter: Clint Morgan
>            Assignee: stack
>            Priority: Blocker
>             Fix For: 0.19.0
>
>         Attachments: 910-v2.patch, hbase-910.patch
>
>
> I first noticed that some columns for a row were missing if they are coming from a scanner that was obtained while a memecache flush on the region was in progress. I tried to write a simple unit test to reproduce, however the problem I get in the unit test is that some rows are being missed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.