[
https://issues.apache.org/jira/browse/HBASE-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900928#action_12900928
]
HBase Review Board commented on HBASE-2915:
-------------------------------------------
Message from: "Jean-Daniel Cryans" <[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 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.
bq.
bq. stack wrote:
bq. 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).
bq.
bq. Jean-Daniel Cryans wrote:
bq. I'm afraid those little methods could be clogged fast.
bq.
bq. stack wrote:
bq. Yeah. Not important.
Moreover, and this should be added to the documentation, none of the
user-facing methods now directly use the lock, it has to go through those new
methods. Means that flush, compact, split and close are the only ones with
direct access.
- Jean-Daniel
-----------------------------------------------------------
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.
