hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Latham (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-8877) Reentrant row locks
Date Tue, 16 Jul 2013 13:46:50 GMT

     [ https://issues.apache.org/jira/browse/HBASE-8877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dave Latham updated HBASE-8877:
-------------------------------

    Attachment: HBASE-8877-refCounts-v5.patch

Attaching HBASE-8877-refCounts-v5.patch
This one's for all the marbles.

 - Reformatted the too-long line (thanks Hadoop QA)
 - improved a log message and an exception message
 - reduced scope of RowLockContext methods from public to package

Here are the changes from HBASE-8877-refCounts-v4.patch to HBASE-8877-refCounts-v5.patch

{noformat}
476,477c476,477
< +  public RowLock getRowLock(final byte[] row, boolean waitForLock)
<    throws IOException {
---
> -  throws IOException {
> +  public RowLock getRowLock(byte[] row, boolean waitForLock) throws IOException {
499c499
< +          // Row is already locked by some other thread
---
> +          // Row is already locked by some other thread, give up or wait for it
505a506,507
> -              throw new IOException("Timed out on getting lock for row="
> -                  + Bytes.toStringBinary(row));
> +              throw new IOException("Timed out waiting for lock for row: " + rowKey);
510c511,516
> -            LOG.warn("internalObtainRowLock interrupted for row=" + Bytes.toStringBinary(row));
> +            LOG.warn("Thread interrupted waiting for lock on row: " + rowKey);
1144c1150
< +    public RowLockContext(HashedBytes row) {
---
> +    RowLockContext(HashedBytes row) {
1149c1155
< +    public boolean ownedByCurrentThread() {
---
> +    boolean ownedByCurrentThread() {
1153c1159
< +    public RowLock newLock() {
---
> +    RowLock newLock() {
1168c1174,1175
< +          throw new RuntimeException("Internal row lock state inconsistent, should not
happen, row: " + row);
---
> +          throw new RuntimeException(
> +              "Internal row lock state inconsistent, should not happen, row: " + row);
{noformat}
                
> Reentrant row locks
> -------------------
>
>                 Key: HBASE-8877
>                 URL: https://issues.apache.org/jira/browse/HBASE-8877
>             Project: HBase
>          Issue Type: Bug
>          Components: Coprocessors, regionserver
>            Reporter: Dave Latham
>            Assignee: Dave Latham
>             Fix For: 0.95.2
>
>         Attachments: hbase-8877-0.94-microbenchmark.txt, HBASE-8877-0.94.patch, HBASE-8877-0.94-v2.patch,
HBASE-8877.patch, hbase-8877-refCounts-microbenchmarks.txt, HBASE-8877-refCounts.patch, HBASE-8877-refCounts-v2.patch,
HBASE-8877-refCounts-v3.patch, HBASE-8877-refCounts-v4.patch, HBASE-8877-refCounts-v5.patch,
HBASE-8877-v2.patch, HBASE-8877-v3.patch, hbase-8877-v4-microbenchmark.txt, HBASE-8877-v4.patch,
HBASE-8877-v5.patch, HBASE-8877-v6.patch, HBASE-8877-v7.patch
>
>
> HBASE-8806 revealed performance problems with batch mutations failing to reacquire the
same row locks.  It looks like HBASE-8806 will use a less intrusive change for 0.94 to have
batch mutations track their own row locks and not attempt to reacquire them.  Another approach
will be to support reentrant row locks directly.  This allows simplifying a great deal of
calling code to no longer track and pass around lock ids.
> One affect this change will have is changing the RegionObserver coprocessor's methods
preBatchMutate and postBatchMutate from taking a {{MiniBatchOperationInProgress<Pair<Mutation,
Integer>> miniBatchOp}} to taking a {{MiniBatchOperationInProgress<Mutation> miniBatchOp}}.
 I don't believe CPs should be relying on these lock ids, but that's a potential incompatibility.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message