hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "HBase Review Board (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2915) Deadlock between HRegion.ICV and HRegion.close
Date Thu, 19 Aug 2010 22:14:19 GMT

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

HBase Review Board commented on HBASE-2915:

Message from: "Jean-Daniel Cryans" <jdcryans@apache.org>

This is an automatically generated e-mail. To reply, visit:

Review request for hbase.


This patch removes newScannerLock and renames splitAndClose lock to just "lock". Every operation
is now required to obtain the read lock on "lock" before doing anything (including getting
a row lock). This is done by calling openRegionTransaction inside a try statement and by calling
closeRegionTransaction in finally.

flushcache got refactored some more in order to do the locking in the proper order; first
get the read lock, then do the writestate handling.

Finally, it removes the need to have a writeLock when flushing when subclassers give atomic
work do to via internalPreFlushcacheCommit. This means that this patch breaks external contribs.
This is required to keep our whole locking mechanism simpler.

This addresses bug HBASE-2915.


  /trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 987300 
  /trunk/src/main/java/org/apache/hadoop/hbase/regionserver/SplitTransaction.java 987300 
  /trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransaction.java 987300

Diff: http://review.cloudera.org/r/691/diff


5 concurrent ICV threads + randomWrite 3 + scans on a single RS. I'm also in the process of
deploying it on a cluster.



> Deadlock between HRegion.ICV and HRegion.close
> ----------------------------------------------
>                 Key: HBASE-2915
>                 URL: https://issues.apache.org/jira/browse/HBASE-2915
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Jean-Daniel Cryans
>            Assignee: Jean-Daniel Cryans
>            Priority: Blocker
>             Fix For: 0.90.0
> HRegion.ICV gets a row lock then gets a newScanner lock.
> HRegion.close gets a newScanner lock, slitCloseLock and finally waits for all row locks
to finish.
> If the ICV got the row lock and then close got the newScannerLock, both end up waiting
on the other. This was introduced when Get became a Scan.
> Stack thinks we can get rid of the newScannerLock in close since we setClosing to true.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message