[
https://issues.apache.org/jira/browse/HBASE-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900922#action_12900922
]
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.
bq.
bq. stack wrote:
bq. Don't you have to check again the setClosing after you get the read
lock?
bq.
bq. Jean-Daniel Cryans wrote:
bq. I'm about to post a new patch, but it looks like this and it has to be
called just before "try" instead of inside:
bq. if (this.closing.get()) {
bq. throw new
NotServingRegionException(regionInfo.getRegionNameAsString() +
bq. " is closing");
bq. }
bq. lock.readLock().lock();
bq. if (this.closed.get()) {
bq. throw new
NotServingRegionException(regionInfo.getRegionNameAsString() +
bq. " is closed");
bq. }
That looks right.
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.
Yeah. 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.
