hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allan Yang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-18144) Forward-port the old exclusive row lock; there are scenarios where it performs better
Date Sat, 17 Jun 2017 13:14:01 GMT

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

Allan Yang commented on HBASE-18144:
------------------------------------

{quote}
Allan Yang Yeah, even with sorting, allowing that threads can be preempted (unscheduled) while
trying to attain locks, there is nothing to prevent your scenario. It does seem harder to
manufacture if locks are being taken in order requiring more parties participating to achieve
deadlock.
{quote}
Are you still facing this problem after sorting? I think this  temporary deadlocking situation
only exists when getting readlock is not ordered.

{quote}
On your #2, above, with read/write locks, we have to take the lock every time so the lock
keep account of reads vs writes outstanding; we can't do the logic that was in branch-1.1.
{quote}
Not quite understand why we can't do the logic in branch-1.1. We can do this in doMiniBatchMutation:
if it is the first row in the batch, wait until we can get its readlock (only one lock won't
cause deadlock), if it is not, use trylock() instead of tryLock(long time, TimeUnit unit),
fail fast and clean up lockcontext(if you are worry about ref counting, we just need to make
sure we clean up the lockcontext after failing to get the lock)

{quote}
Other thoughts are that the doMiniBatch where it takes all locks up front before going on
to apply Mutations is not appropriate after the move to read/write row locks; it made sense
in branch-1.1. where the row lock was costly and reentrant. Once you had the lock, you could
do a bunch of mutations under its umbrella. When read/write lock, the lock does the refcounting
internally. If all read lock requests, then all threads make progress. Its the write lock
requests that are blockers. 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? Someone probably figured the heuristic long ago. We need to do a bit of
study.
{quote}
doMiniBatch is not trying to get all locks before moving to the next step, on the contrary,
if getting locks fails, doMiniBatch will apply mutations on rows which's readlock have gotten
successfully. The failed ones in the batch will be retried in batchMutate()
The only problem in branches other than branch-1.1 is that we are waiting on readlock everytime
now. 

{quote}
On the sort, it costs. Was wondering if we could exploit the sort otherwise perhaps later
in the processing of mutations (is this the only sort in the write pipeline?)
{quote}
Yes, I'm pretty sure this is the only sort in the write pipeline. Why sorting later in the
processing of mutations is better?


> 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