hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-18474) HRegion#doMiniBatchMutation is acquiring read row locks
Date Fri, 28 Jul 2017 20:15:00 GMT

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

Andrew Purtell updated HBASE-18474:
-----------------------------------
    Description: 
Looking at 1.3, HRegion#doMiniBatchMutation is acquiring read row locks in step 1. 
{code}
        // If we haven't got any rows in our batch, we should block to                   
                                                       
        // get the next one.                                                             
                                                       
        RowLock rowLock = null;
        try {
          rowLock = getRowLockInternal(mutation.getRow(), true);
        } catch (TimeoutIOException e) {
          // We will retry when other exceptions, but we should stop if we timeout .     
                                                       
          throw e;
        } catch (IOException ioe) {
          LOG.warn("Failed getting lock in batch put, row="
            + Bytes.toStringBinary(mutation.getRow()), ioe);
        }
        if (rowLock == null) {
          // We failed to grab another lock                                              
                                                       
          break; // stop acquiring more rows for this batch                              
                                                       
        } else {
          acquiredRowLocks.add(rowLock);
        }
{code}


Other code paths that apply mutations are acquiring write locks.

In HRegion#append
{code}
    try {
      rowLock = getRowLockInternal(row, false);
      assert rowLock != null;
...
{code}

In HRegion#doIn
{code}
    try {
      rowLock = getRowLockInternal(increment.getRow(), false);
...
{code}

In HRegion#checkAndMutate
{code}
      // Lock row - note that doBatchMutate will relock this row if called               
                                                       
      RowLock rowLock = getRowLockInternal(get.getRow(), false);
      // wait for all previous transactions to complete (with lock held)                 
                                                       
      mvcc.await();
{code}

What doMiniBatchMutation is doing looks wrong. 

> HRegion#doMiniBatchMutation is acquiring read row locks
> -------------------------------------------------------
>
>                 Key: HBASE-18474
>                 URL: https://issues.apache.org/jira/browse/HBASE-18474
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Andrew Purtell
>
> Looking at 1.3, HRegion#doMiniBatchMutation is acquiring read row locks in step 1. 
> {code}
>         // If we haven't got any rows in our batch, we should block to              
                                                            
>         // get the next one.                                                        
                                                            
>         RowLock rowLock = null;
>         try {
>           rowLock = getRowLockInternal(mutation.getRow(), true);
>         } catch (TimeoutIOException e) {
>           // We will retry when other exceptions, but we should stop if we timeout .
                                                            
>           throw e;
>         } catch (IOException ioe) {
>           LOG.warn("Failed getting lock in batch put, row="
>             + Bytes.toStringBinary(mutation.getRow()), ioe);
>         }
>         if (rowLock == null) {
>           // We failed to grab another lock                                         
                                                            
>           break; // stop acquiring more rows for this batch                         
                                                            
>         } else {
>           acquiredRowLocks.add(rowLock);
>         }
> {code}
> Other code paths that apply mutations are acquiring write locks.
> In HRegion#append
> {code}
>     try {
>       rowLock = getRowLockInternal(row, false);
>       assert rowLock != null;
> ...
> {code}
> In HRegion#doIn
> {code}
>     try {
>       rowLock = getRowLockInternal(increment.getRow(), false);
> ...
> {code}
> In HRegion#checkAndMutate
> {code}
>       // Lock row - note that doBatchMutate will relock this row if called          
                                                            
>       RowLock rowLock = getRowLockInternal(get.getRow(), false);
>       // wait for all previous transactions to complete (with lock held)            
                                                            
>       mvcc.await();
> {code}
> What doMiniBatchMutation is doing looks wrong. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message