hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Daniel Cryans (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2915) Deadlock between HRegion.ICV and HRegion.close
Date Thu, 19 Aug 2010 17:23:16 GMT

    [ https://issues.apache.org/jira/browse/HBASE-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900367#action_12900367
] 

Jean-Daniel Cryans commented on HBASE-2915:
-------------------------------------------

There is another deadlock that needs fixing in the scope of this jira. Since the split code
was redone, there's a deadlock when SplitTransaction acquires the splitAndCloses writelock
while a flush is running for it. It looks like:

{noformat}

"regionserver60021.compactor" daemon prio=10 tid=0x00007fc31845b800 nid=0x5f62 in Object.wait()
[0x00007fc31e9e7000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:485)
	at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:493)
	- locked <0x00007fc336877998> (a org.apache.hadoop.hbase.regionserver.HRegion$WriteState)
	at org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:213)
	at org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:186)
	at org.apache.hadoop.hbase.regionserver.CompactSplitThread.split(CompactSplitThread.java:157)
	at org.apache.hadoop.hbase.regionserver.CompactSplitThread.run(CompactSplitThread.java:87)

"regionserver60021.cacheFlusher" daemon prio=10 tid=0x00007fc31845a000 nid=0x5f61 waiting
on condition [0x00007fc31eae8000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00007fc336561750> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:877)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1197)
	at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:594)
	at org.apache.hadoop.hbase.regionserver.HRegion.flushcache(HRegion.java:793)
	at org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:249)
	at org.apache.hadoop.hbase.regionserver.MemStoreFlusher.flushRegion(MemStoreFlusher.java:223)
	at org.apache.hadoop.hbase.regionserver.MemStoreFlusher.run(MemStoreFlusher.java:146)
{noformat}

> 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
>            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.


Mime
View raw message