[
https://issues.apache.org/jira/browse/HBASE-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900919#action_12900919
]
HBase Review Board commented on HBASE-2915:
-------------------------------------------
Message from: [email protected]
bq. On 2010-08-20 15:57:34, stack wrote:
bq. > /trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java,
line 507
bq. > <http://review.cloudera.org/r/691/diff/1/?file=7612#file7612line507>
bq. >
bq. > 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.
bq.
bq. Jean-Daniel Cryans wrote:
bq. So I just redid that part. setClosing is first taken so that when the
client threads arrive they can fast fail by looking at closing.get before
trying to get the readLock.
Don't you have to check again the setClosing after you get the read lock?
bq. On 2010-08-20 15:57:34, stack wrote:
bq. > /trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java,
line 712
bq. > <http://review.cloudera.org/r/691/diff/1/?file=7612#file7612line712>
bq. >
bq. > Seems like you could use your opentransaction/closetransaction
methods here and in flush too to be consistent?
bq.
bq. Jean-Daniel Cryans wrote:
bq. Yeah the issue with compact and flush is that the callers don't expect
to see NSRE, the want null values.
OK. Not important. This is deep internal stuff or make a version that takes a
flag on whether to throw exception (default throws exception .. might get messy
though... not important).
- stack
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/691/#review974
-----------------------------------------------------------
> 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.
