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

Mikhail Antonov commented on HBASE-17887:
-----------------------------------------

[~ram_krish] oh, I totally didn't intend to assign blame to anyone, rather to 
provide additional context and my perspective in response to Lars' comment.

I think demonstrated performance gains of that patch totally justified changing 
locking schema, and this patch went through numerous rounds of very thorough 
reviews from lots of people (if anything, the bugs founds after might have 
revealed that test coverage around storefile accounting/archiving needed some 
work, which was done, so it's good).

I think at this point I'd want to keep this change in 1.3 line and address 
issues as they arise, rather then try to revert it. We'd lose perf benefits 
from it and (perhaps more important) the revert would be a really massive 
patch. Let's roll forward, not backward.



> Row-level consistency is broken for read
> ----------------------------------------
>
>                 Key: HBASE-17887
>                 URL: https://issues.apache.org/jira/browse/HBASE-17887
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>    Affects Versions: 2.0.0, 1.3.0
>            Reporter: Umesh Agashe
>            Assignee: Chia-Ping Tsai
>            Priority: Blocker
>             Fix For: 2.0.0, 1.4.0, 1.3.2
>
>         Attachments: HBASE-17887.branch-1.v0.patch, 
> HBASE-17887.branch-1.v1.patch, HBASE-17887.branch-1.v1.patch, 
> HBASE-17887.branch-1.v2.patch, HBASE-17887.branch-1.v2.patch, 
> HBASE-17887.branch-1.v3.patch, HBASE-17887.branch-1.v4.patch, 
> HBASE-17887.branch-1.v4.patch, HBASE-17887.branch-1.v4.patch, 
> HBASE-17887.branch-1.v5.patch, HBASE-17887.branch-1.v6.patch, 
> HBASE-17887.ut.patch, HBASE-17887.v0.patch, HBASE-17887.v1.patch, 
> HBASE-17887.v2.patch, HBASE-17887.v3.patch, HBASE-17887.v4.patch, 
> HBASE-17887.v5.patch, HBASE-17887.v5.patch
>
>
> The scanner of latest memstore may be lost if we make quick flushes. The 
> following step may help explain this issue.
> # put data_A (seq id = 10, active store data_A and snapshots is empty)
> # snapshot of 1st flush (active is empty and snapshot stores data_A)
> # put data_B (seq id = 11, active store data_B and snapshot store data_A)
> # create user scanner (read point = 11, so It should see the data_B)
> # commit of 1st flush
> #* clear snapshot ((hfile_A has data_A, active store data_B, and snapshot is 
> empty)
> #* update the reader (the user scanner receives the hfile_A)
> # snapshot of 2st flush (active is empty and snapshot store data_B)
> # commit of 2st flush
> #* clear snapshot (hfile_A has data_A, hfile_B has data_B, active is empty, 
> and snapshot is empty) – this is critical piece.
> #* -update the reader- (haven't happen)
> # user scanner update the kv scanners (it creates scanner of hfile_A but 
> nothing of memstore)
> # user see the older data A – wrong result



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to