[
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
(v6.4.14#64029)
