[
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 4:08 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 through codes.
IMHO, all simple put (single or batch) requests only take 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. 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.
> 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)
