hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-5121) MajorCompaction may affect scan's correctness
Date Sun, 08 Jan 2012 02:41:39 GMT

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

Lars Hofhansl updated HBASE-5121:
---------------------------------

    Attachment: 5121-suggest.txt

I was looking at the patch a bit. Maybe there is a simpler solution:
You say in that when this scenario happens the KV just "vanishes".
What your logic in KeyValueHeap is essentially doing is to retry with the next KV on the heap.
So, we can just tell the KeyValueHeap that there are more KVs in this case (returning true
for mayContainMoreRows).

With this your test passes.
(it is entirely possible that my reasoning is incorrect, and it just accidentally lets the
test pass).
                
> MajorCompaction may affect scan's correctness
> ---------------------------------------------
>
>                 Key: HBASE-5121
>                 URL: https://issues.apache.org/jira/browse/HBASE-5121
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>    Affects Versions: 0.90.4
>            Reporter: chunhui shen
>            Assignee: chunhui shen
>            Priority: Critical
>             Fix For: 0.94.0, 0.92.1, 0.90.6
>
>         Attachments: 5121-suggest.txt, 5121-trunk-combined.txt, 5121.90, hbase-5121-testcase.patch,
hbase-5121.patch, hbase-5121v2.patch
>
>
> In our test, there are two families' keyvalue for one row.
> But we could find a infrequent problem when doing scan's next if majorCompaction happens
concurrently.
> In the client's two continuous doing scan.next():
> 1.First time, scan's next returns the result where family A is null.
> 2.Second time, scan's next returns the result where family B is null.
> The two next()'s result have the same row.
> If there are more families, I think the scenario will be more strange...
> We find the reason is that storescanner.peek() is changed after majorCompaction if there
are delete type KeyValue.
> This change causes the PriorityQueue<KeyValueScanner> of RegionScanner's heap is
not sure to be sorted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message