[
https://issues.apache.org/jira/browse/HBASE-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900510#action_12900510
]
HBase Review Board commented on HBASE-2915:
-------------------------------------------
Message from: "Ryan Rawson" <[email protected]>
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/691/#review966
-----------------------------------------------------------
/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
<http://review.cloudera.org/r/691/#comment3144>
oh wow i cant believe this was ever here
/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
<http://review.cloudera.org/r/691/#comment3145>
i thought we agreed that the closing flag had to be set BEFORE the write
lock was acquired to prevent race conditions?
/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
<http://review.cloudera.org/r/691/#comment3146>
lets just excise this and break compile time compatibility. Also remove
internalPreFlushcacheCommit too
/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
<http://review.cloudera.org/r/691/#comment3147>
ditto remove this whole try/finally bit
/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
<http://review.cloudera.org/r/691/#comment3148>
maybe we shouldnt call this 'transaction' might confuse people into
thinking we support real transactions... not sure what to call it at this
moment tho
- Ryan
> 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.
