hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yu Li (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-18144) Forward-port the old exclusive row lock; there are scenarios where it performs better
Date Mon, 19 Jun 2017 03:55:01 GMT

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

Yu Li edited comment on HBASE-18144 at 6/19/17 3:54 AM:
--------------------------------------------------------

bq. Any idea which issue changed this way? Yu Li
It's HBASE-12751/HBASE-14465, which removed the {{boolean shouldBlock = numReadyToWrite ==
0;}} logic. And our boss stack has clarified reason for the change.

Happen to know this since I've backported this "Allow Rowlock to be reader writer" feature
to our customized 1.1.2 (smile). As mentioned before, in our search scenario we don't have
increment requests so luckily never ran into this issue. [~anoop.hbase]

bq.  Better to have the batch fail quickly with a bunch of read-lock successes than have it
wait (deadlock) for 30 seconds at a time just because the batch had a write lock in the mix
that it was unable to attain in time; better to fail fast and then retry on a new rpc?
Exactly, and I think the old *shouldBlock* trick could achieve this, which means we won't
wait for any write lock if we're already holding read locks in the batch. And if we failed
to attain any read lock in mid of one doMiniBatchMuation round, we will fail fast (return
null lock and break the while loop, write those edits with locks successfully attained, release
locks, then return). In this case {{batchOp.isDone}} in {{batchMutate}} returns false and
we will try another doMiniBatchMutation. Allan's HBASE-18233 patch shows the logic in codes.

IMHO, all simple put (single or batch) only takes read lock, while append/increment/checkAndXXX
takes write lock. One put batch will be split into multiple rounds if it failed to attain
any read lock in doMiniBatchMutation, after each round it will release the taken read lock
so won't block later operations. This is why I think the shouldBlock flag also works with
read/write lock. But maybe I'm not getting the point and could you further clarify if so boss
[~stack]? Thanks.


was (Author: carp84):
bq. Any idea which issue changed this way? Yu Li
It's HBASE-12751/HBASE-14465, which removed the {{boolean shouldBlock = numReadyToWrite ==
0;}} logic. And our boss stack has clarified reason for the change.

Happen to know this since I've backported this "Allow Rowlock to be reader writer" feature
to our customized 1.1.2 (smile). As mentioned before, in our search scenario we don't have
increment requests so luckily never ran into this issue. [~anoop.hbase]

bq.  Better to have the batch fail quickly with a bunch of read-lock successes than have it
wait (deadlock) for 30 seconds at a time just because the batch had a write lock in the mix
that it was unable to attain in time; better to fail fast and then retry on a new rpc?
Exactly, and I think the old *shouldBlock* trick could achieve this, which means we won't
wait for any write lock if we're already holding read locks in the batch. And if we failed
to attain any read lock in mid of one doMiniBatchMuation round, we will fail fast (return
null lock and break the while loop, write those edits with locks successfully attained, release
locks, then return). In this case {{batchOp.isDone}} in {{batchMutate}} returns false and
we will try another doMiniBatchMutation. Allan's HBASE-18233 patch shows the logic in codes.

IMHO, all simple put (single or batch) only takes read lock, while append/increment/checkAndXXX
takes write lock. One put batch will be split into multiple rounds if it failed to attain
any read lock in doMiniBatchMutation, after each round it will release the taken read lock
so won't block later operations. Maybe I'm not getting your point and could you further clarify
if so boss? [~stack]? Thanks.

> Forward-port the old exclusive row lock; there are scenarios where it performs better
> -------------------------------------------------------------------------------------
>
>                 Key: HBASE-18144
>                 URL: https://issues.apache.org/jira/browse/HBASE-18144
>             Project: HBase
>          Issue Type: Bug
>          Components: Increment
>    Affects Versions: 1.2.5
>            Reporter: stack
>            Assignee: stack
>             Fix For: 2.0.0, 1.3.2, 1.2.7
>
>         Attachments: DisorderedBatchAndIncrementUT.patch, HBASE-18144.master.001.patch
>
>
> Description to follow.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message