[
https://issues.apache.org/jira/browse/HBASE-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900914#action_12900914
]
HBase Review Board commented on HBASE-2915:
-------------------------------------------
Message from: [email protected]
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/691/#review974
-----------------------------------------------------------
Ship it!
+1 Nice fix. A few comments below.
/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
<http://review.cloudera.org/r/691/#comment3163>
I suppose this order is ok if the first thing we do on entrance to HRegion
is get the read lock before check of closing.
/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
<http://review.cloudera.org/r/691/#comment3164>
Seems like you could use your opentransaction/closetransaction methods here
and in flush too to be consistent?
/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
<http://review.cloudera.org/r/691/#comment3165>
Yeah, just remove.
/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
<http://review.cloudera.org/r/691/#comment3166>
Aren't these lines unnecessary? openRegionTransaction does it?
/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
<http://review.cloudera.org/r/691/#comment3167>
So, this javadoc is good but do you think we need some more doc? Does
there need to be more detail on new locking regime? Maybe there is no more to
be said that what is here in this paragraph. You've done all the work
unravelling our lock mess. With time your nice unravelling will rot unless its
clear what the pattern is. I'm just trying to think of ways of preventing
that happening.
- stack
> 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.
