hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Antonov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17887) Row-level consistency is broken for read
Date Mon, 15 May 2017 05:02:05 GMT

    [ 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)

Mime
View raw message