hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Yu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-11945) Client writes may be reordered under contention
Date Thu, 11 Sep 2014 03:12:34 GMT

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

Ted Yu commented on HBASE-11945:
--------------------------------

bq. C1: manages to acquire the lock for a later row2 op

In HRegion#doMiniBatchMutation() around line 2570:
{code}
        if (rowLock == null) {
          // We failed to grab another lock
          assert !shouldBlock : "Should never fail to get lock when blocking";
          break; // stop acquiring more rows for this batch
{code}
Would the above code prevent lock acquisition ?

> Client writes may be reordered under contention
> -----------------------------------------------
>
>                 Key: HBASE-11945
>                 URL: https://issues.apache.org/jira/browse/HBASE-11945
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>    Affects Versions: 0.98.6
>            Reporter: Todd Lipcon
>
> I haven't seen this bug in practice, but I was thinking about this a bit and think there
may be a correctness issue with the way that we handle client batches which contain multiple
operations which touch the same row. The client expects that these operations will be performed
in the same order they were submitted, but under contention I believe they can get arbitrarily
reordered, leading to incorrect results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message