hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (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 17:55:01 GMT

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

stack commented on HBASE-18144:

bq. Are you still facing this problem after sorting?

>From the description "A big problem was our inability at being able to faithfully reproduce
the loading locally (Esteban Gutierrez and I made distinct attempts in two different environments)...."

I am working at trying the sort on the remote cluster. Will report back if it makes a difference.

bq. Not quite understand why we can't do the logic in branch-1.1. 

How would you do it? Previous, the vocabulary was basic, a thread had the lock or it did not.
Now, the lock is read/write. Any amount of threads can concurrently hold the read lock. How
would you do low-friction accounting of read vs write across many threads? What you thinking?

bq.  if getting locks fails, doMiniBatch will apply mutations on rows which's readlock have
gotten successfully. 

I reread the code. You are right. Forget my suggestion. It is what we do now (we should never
wait 30 seconds on a lock though... we should drop this way down).

bq. The only problem in branches other than branch-1.1 is that we are waiting on readlock
everytime now.

Is this a problem? Getting a read lock is low cost lockless queue manipulation. If you have
a better alternative, a low-cost means of skirting locks, I'm all ears.

bq. ...I'm pretty sure this is the only sort in the write pipeline. Why sorting later in the
processing of mutations is better?

It would be good to confirm. We repeat lots of work/functions processing reads and writes
whether getting the time or taking locks, etc. I was suggesting we ensure we sort once. I
was then asking if we could exploit the fact that the batch is sorted elsewhere in the write
processing? Or require input to be sorted and just have the client do the sort before sending
in the batch so the server doesn't have to do it; server just runs check that sort was done.
Anyways, just suggestions. Would be good if we sort the batch once only.

> 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

View raw message